Triggers
A workflow starts in one of three ways: by hand, when a record changes, or on a schedule. You choose which in the settings above the canvas, and refine it on the Trigger step, the one step every workflow begins with.
Where to find it
Architect Panel → Automation:
- Workflow Builder — open a workflow; the Starts setting is above the canvas and the Trigger step is the first card
The three ways to start
- By hand: started from the builder's Test dialog, from a record's Processes pane (Run a workflow), by a journey, or by an inbound-message route (see Receiving Messages).
- When a record changes: a record of the target datastore is added, changed or deleted.
- On a schedule: every so many minutes, hours, days or weeks, with or without records to work through.
Only a published, active workflow is started by a record change or a schedule. A draft never is.
Starting when a record changes
- Set Works on records in to the datastore.
- Set Starts to When a record changes, and Record change to A record is added, A record is changed or A record is deleted.
- Set Runs:
- After the record is saved: the usual choice. The workflow reacts to a settled change and may wait, ask for approval and send messages.
- Before it is saved (can check or change it): the workflow runs during the save. It can set the record's fields, and an End step marked Failed refuses the save, showing its message to the person saving. It cannot wait.
- Select the Trigger step and, if you need them, fill in its start conditions (below).
- Save, then Publish. Saving or publishing an event workflow makes sure the datastore passes its record changes to the workflow engine (it creates a table rule for the datastore when none exists), and the note under the settings says whether this is in place. Nothing starts the workflow until it is published.
Start conditions on the Trigger step
- Start only when: rules that must all hold for the record as saved. Any other save starts nothing, so Run History shows only the runs that matter. Values may use {{today}}, {{today-30}} and {{now}}.
- Not while a run of this workflow is still going on the same record: a second save while the first run waits (for an approval, say) does not start a second run.
Use these rather than a Condition straight after the Trigger: a Condition still creates a run for every save, and the history fills with runs that stopped at their first check.
Starting on a schedule
- Set Starts to On a schedule and Runs every to a number and a unit (minutes, hours, days or weeks).
- Select the Trigger step and choose under Each time it runs:
- Run once, with no particular record.
- Start a separate run for each matching record: each record gets its own run, history, waits and approvals. A record whose previous run is still going is skipped.
- Work through the matching records in one run: a For each step after the Trigger repeats its path for every record.
- For the last two, add rules under Only records where (none means every record) and set At most this many records each time (500 when left blank, 5,000 at most).
- Publish. Once it is active, the Trigger step shows Last ran and Runs next.
Two buttons sit under the schedule. Run on the next tick brings the next run forward. Run this schedule now… runs this workflow's schedule immediately, for real; it needs the owner role or an architect.
The Workflow Scheduler task
Scheduled workflows are started by the task Workflow Scheduler (scheduled workflows). It is installed switched off and in preview mode, and checks every 5 minutes, so no schedule runs more often than that. An architect turns it on from the Tasks screen; the help under Runs every says when it is off and offers Open Tasks. See Tasks.
What goes wrong
- "Not wired yet" in Problems: no table rule passes the datastore's changes to the engine. Save, publish or activate the workflow to wire it.
- A workflow re-triggers itself. An update workflow that updates its own record starts again. Narrow it with Start only when, or tick Not while a run is still going.
- Thousands of runs after an import. Every added record starts a run. Add start conditions, or disable the workflow during the import.
- A scheduled run has no record. With Run once, steps that read the record have nothing to read; choose one of the record options.
Worked example
A purchasing team wants approval to start only when an order is sent for approval. The workflow works on purchase orders, starts When a record changes, A record is changed, After the record is saved. On the Trigger step, Start only when says the status equals Pending Approval, and Not while a run is still going is ticked. Saving a draft order starts nothing; sending it for approval starts one run, and saving it again while the approver decides starts no second request.
Recommendations
- Use After unless you need to change or refuse the save itself.
- Put start conditions on the Trigger rather than in a first Condition.
- Tick Not while a run is still going on any workflow that waits for a person.
- Turn the Workflow Scheduler task on before relying on a schedule.
- Prefer one run per record for scheduled work that waits or asks for approval.