Automations
Overview
How a workflow is built, versioned and run.
How a workflow is built
A workflow listens for one trigger, checks any enrolment conditions, then runs up to 50 steps in order. Steps can perform an action, pause for a period, or stop the run when a condition does not pass.
Trigger
The event or schedule that starts a run.
Trigger filters
Optional form, tag, pipeline, stage, or data checks applied before enrolment.
Steps
An ordered sequence of actions, waits, and continue-if conditions.
Run
One durable execution for a contact, or one contactless execution for a schedule.
Create and publish a workflow
- Open Automations and select New automation.
- Name the workflow and open its Builder tab.
- Choose the trigger and narrow it with filters or enrolment conditions when needed.
- Add actions in the order they should run. Use the arrow buttons to reorder them.
- Select Save to keep a draft, then Publish when it is ready to receive events.
Versions protect runs in progress
Saving an unpublished draft updates that draft. Saving changes after a version has been published creates the next version instead. Existing runs continue with the exact published version they started on; the new draft takes over only after you publish it.
This means a long wait does not silently switch to newly edited steps halfway through. The Runs tab shows the version number used by each execution.
Workflow and run states
Draft
Editable, but not listening for triggers.
Active
Published and eligible to start new runs.
Paused
Keeps its published version but stops new enrolments.
Archived
Removed from active use. Past run records are retained.
Pending / Running
A run is queued or currently executing steps.
Waiting
A wait is in progress or a failed step is awaiting a retry.
Completed
All steps finished, or a condition ended the run normally.
Failed
A step still failed after its final automatic attempt.
Runs continue in the background
Systemly puts trigger matching and step execution onto its durable worker queue. You can close the browser after publishing; waits, retries, and later actions do not depend on the builder remaining open.
Learn the available starting events in Triggers, then review every step in Actions.
Access and plan requirements
Workspace permissions separate reading workflows, editing them, and publishing them. Publishing also requires a plan with automations enabled. A teammate who can view runs may still be unable to change or activate the workflow.