Triggers
A workflow names the datastore it acts on and what starts it.
Where to find it
Architect Panel → Automation:
- Workflow Builder — the canvas, nodes and edges
- Worklist — what is waiting on a person
The trigger has three parts
- Type — an event on a record, or a schedule.
- Event — what happened.
- When — before or after that event is processed.
Only active workflows are matched, so a draft can exist safely alongside a live one.
Before or after
The decision that causes most confusion.
- Before — the workflow runs while the change is still in progress. Use it where you need to affect the record as it is saved.
- After — the change is committed. Use it for anything reacting to a settled fact: notifying, creating related records, starting a process.
After is right most of the time. Before is for the cases where the change itself needs to be shaped.
Scheduled workflows
Run on a frequency rather than in response to a record change. Useful for anything that has to happen regardless of activity — a periodic review, a sweep for records that have gone stale.
One trigger per workflow
Which keeps each one comprehensible. A workflow that should start in two circumstances is usually two workflows, or one workflow whose first node is a condition.
Beware the loop
A workflow triggered by an update that itself updates the record will trigger again. The step budget stops it eventually, and eventually is not soon enough.
Where a workflow writes to its own target, make the trigger narrow enough that the write cannot match it.
Narrow the trigger, not just the condition
A workflow that starts on every save and immediately evaluates a condition starts constantly. Where the trigger can be more specific, make it so — it is cheaper and the run history stays readable.
Think about volume
A trigger on a high-volume datastore starts a run per record. Consider what that means during an import of ten thousand rows, and whether the workflow should be excluded from bulk operations.
Test the trigger first
Before building the rest. Activate a workflow with a single harmless node, cause the event, and confirm a run appears. Establishing that the trigger fires removes the largest unknown.
Worked example
A workflow triggers after a case is created, not before, because everything it does depends on the record existing. A second workflow triggers after a status change specifically, rather than on any update, so an import of notes does not start thousands of runs.
Recommendations
- After, unless you need to shape the change.
- Narrow the trigger rather than filtering afterwards.
- Watch for self-triggering loops.
- Prove the trigger fires before building the workflow.