Create a Listener Workflow v2

A listener Workflow remains active and waits for a supported Node Method to receive an external event or batch.

Build the listener

  1. Create a Workflow in the Test Environment.
  2. Select the Cluster on which the entire Workflow must run.
  3. Add a supported listener Node Method as the root trigger Step.
  4. Select or create its Connection when required.
  5. Map the trigger Returns into the processing Steps.
  6. Add bounded error handling and log-safe operational context.

The exact listener Parameters and Returns come from its Node Method contract. Confirm that the Node and Connection both support the Workflow's selected Cluster. The Runtime does not route a single listener Step through a v1 Runtime DropPoint.

Test and publish

  1. Use Debug with a safe event source or representative samples where the listener supports it.
  2. Inspect Problems and logs.
  3. Save the Workflow.
  4. Publish or promote it to the target Environment.
  5. Configure the Connection values for that Environment.
  6. Enable the Workflow.

Verify activation

Allow a short refresh period after publishing or changing the status, Connection, or Cluster selection. Confirm the listener from Workflow logs and a controlled source event.

Disabling the Workflow prevents new listener starts and causes its continuous listener instance to drain during reconciliation. If it does not become active, check publish, Environment status, Cluster hosts, Connection validity, Node placement support, and capacity.

Worked example: watch a local folder

Use the File Listen Method on a Run Anywhere Cluster that can access a test folder. The path is on the Cluster host, so each eligible host must have the intended filesystem access.

  1. Create a Workflow with New Workflow in Test and select the Run Anywhere Cluster.
  2. Add File → Listen at the root and name the Step watchFiles.
  3. Set Path to an accessible test folder, Mask to *.txt, PollInterval to 5, FolderDepthLimit to 0, and FindMatchesOnStart to false.
  4. Add a For Each Step named processFiles and map Items to {watchFiles.Files}. Retain the String field ChangedFilePath in its item schema.
  5. Add File → Read inside the loop and map its Path Parameter to {processFiles.Items.ChangedFilePath}.
  6. Start Debug and create a small .txt file in the test folder. Inspect the listener result and the nested read Step in Logs, then stop Debug.

The listener returns the matching file path and the loop runs the read Step for that item. With a five-second polling interval, allow time for the next poll. Use a disposable folder and avoid editing the same file repeatedly during this first test.

Save, publish, and enable the Workflow when the test succeeds. Create another file and confirm a published listener activation processes it. File notifications are not a business-level exactly-once guarantee: use a stable record identifier and idempotent processing when a repeated notification could duplicate a write.

See also

See Triggers, Workflow Status, and Local System Integration.