Invocation
Split automation into reusable pieces by having one workflow invoke another, and track invocations with trigger states.
You can split a large automation into reusable pieces by having one workflow invoke another. The parent runs an Invoke Workflow action, and the child workflow is made invokable so it can be called. Whether the child actually fires is gated by the inputs it requires, which you can follow in the Trigger States tab. For the building blocks, see Build a workflow.
Make a workflow invokable
Before a workflow can be called by another, turn on its invocation settings:
- Open the child workflow in the editor, click the toolbar's ⋯, and choose Invocation settings.
- Turn on Make this workflow invokable.
- Optionally add Required inputs: type an input name and press Enter (or click Add) for each one. These are the inputs that must be provided before the workflow triggers; leave the list empty to trigger immediately on invocation.
- Optionally mark some of them as Persistent inputs (see below).
- Click Save.
Invocation settings aren't available for workflows that start with a Schedule Trigger, which are started by their schedule instead.
Persistent inputs
Normally a trigger state is used up when it fires, so every required input has to arrive again before the next run. That suits a delivery, such as a positions file, but not a referential, such as a securities file: once securities have arrived for a business date, a re-delivered positions file for that date should re-run without waiting for a securities file that will not come twice.
Under Persistent inputs, click a required input's chip to mark it. A persistent input stays received for its context group once it has arrived, so a re-delivered input re-triggers the workflow without the persistent ones arriving again. Mark referential inputs; leave delivery-style inputs unmarked.
Persistence is kept per context group, the values the Context Mapping passes. An Invoke Workflow step that targets a workflow with persistent inputs must therefore have a context mapping, otherwise the step is refused, since every invocation would share one group and "stays received" would mean received once, ever.
Invoke it from a parent workflow
In the parent workflow, add the Invoke Workflow action (in the Custom group) and configure it in the side panel:
- Target Workflow is the workflow to run. Only workflows with invocation settings turned on appear here; with none, the list says No invokable workflows found. Set up invocation config on a workflow first.
- Provides Input declares which of the target's required inputs this invocation satisfies. It appears when the target defines required inputs.
- Context Mapping feeds the target's context variables. Click Add mapping and pair a Source column from the previous action's output with a Target variable. It appears when you have picked a target; a target with no variables says Target workflow has no context variables defined.
The Invoke Workflow action has no field, operator and value condition and no "wait for completion" option. What decides whether the child runs is its Required inputs: the child stays pending until every required input has been provided, then fires.
Track invocations with trigger states
An invokable workflow that's waiting on its inputs shows up in the Trigger States tab of the workflow section. Each row is one pending invocation, with columns for Status, Inputs, Context, Created and Triggered, and a status filter.
| Trigger state | Meaning |
|---|---|
| Pending | Waiting for one or more required inputs |
| Ready | All required inputs received; about to run |
| Triggered | Fired; the run has started |
| Expired | Timed out before all inputs arrived |
If a child workflow never runs, check its trigger state here: Pending means an expected input hasn't been provided yet. Open a row to see its Required inputs, which have been received, the Context values it was invoked with, and when it was created, expires or triggered.