Advanced automations

Configuration · Automation · 9.2.1

A simple rule fires once and is done: trigger, conditions, a couple of actions. The engine can do much more than that. Steps can run at the same time, a wait can hold the rest of the rule for hours or weeks, a condition gate can split the happy path from the exception, and a branch per record can follow each created task through its own life. That is what turns a rule into a process: one definition that starts on day one and quietly finishes itself three weeks later.

This page explains every one of those options. If you have not built a basic rule yet, start with Automations; if you want to see the options combined into real processes, continue with Automation use cases.

Two views of one rule: Editor and Diagram

Editor

A numbered step list you fill in top to bottom. Best for writing the content of steps: recipients, field values, task details, criteria.

Diagram

The same rule as a flowchart: the trigger on the left, every step as a box, parallel lanes side by side, waits and gates drawn where they hold the flow. Best for checking the shape of a process, and you can insert and move steps right on the chart.

Both views edit the same rule, so nothing is lost by switching. A good habit for anything with branches: build in the Editor, then read the Diagram and check that the drawing matches the process you had in your head. If a step hangs off the wrong branch, you see it in seconds there.

When does a step start?

Every step you add gets one of two starting modes. The picker asks for it explicitly:

Mode	Meaning
After the previous step	The step chains onto the step above it. If that step created tasks that are still open, this one waits for them first; otherwise it simply runs next.
At the same time	The step runs together with the steps above it, nothing waits. Placed at the same time as a step that creates records, it opens an independent parallel lane: its own track in the diagram, with its own waits, finishing in whatever order its work completes.

Parallel lanes are how one rule serves several departments at once: an IT lane, an HR lane and a Facilities lane each create their own tasks and wait for their own people, and none of them blocks the others. A join step (see below) is where the lanes come back together.

Condition gates

The Condition step is a gate in the middle of the flow: continue only when the criteria match. When they do not, the steps behind the gate are skipped and the run history records “halted by an earlier condition step” on each of them, so you can always see which gate closed.

Two properties make gates precise:

A gate only holds its own path. Inside a branch or a lane it gates that branch; on the main path it gates everything below it. The diagram draws exactly what it holds.
A gate is instant. It checks the record as it is at that moment and moves on. If you want to wait for the record to become something, that is a wait, not a gate.

Use a gate where a process forks on data that is already there (“is this an external visitor?”); use per-step conditions where only one step is optional; use a wait where the answer does not exist yet.

Waits: four kinds

A Wait step holds everything below it until something happens. There are four kinds, and the editor only offers the ones that make sense at that spot.

Wait for	How it works
On the tasks above	Watches every task created above the wait. By default it releases when they are all finished (a status of class Approved, Cancelled or Rejected); set your own release criteria and it releases the moment every task matches them instead. A task that finishes without ever matching stops the rule, because the outcome you waited for can no longer happen.
At a specific moment	A pause on the clock, anchored to the trigger, to a date field on the record (the start date, the due date, a custom date field) or to the previous wait, plus an offset before or after it. "Three days before the start date" is this kind.
When a record from an earlier step changes	Watches the record an earlier step created (a task, a ticket, a booking) or the record the rule runs on, and releases as soon as it matches your criteria. You can also wait for the record to be deleted, which stops the rule instead. This is how you build approvals: create the request, then wait until someone sets it to approved.
Until the branches are done	The join: collects the branches and lanes opened above it and continues once, with everything they produced. You choose what happens when a branch stops early: ignore it and wait for the rest, stop the whole rule, or continue right away with the branches that finished.

Time limits

Every wait can carry a time limit: give up after so many hours or days, and then either run the steps below anyway or stop the rule. Without a limit a task wait or a moment simply waits as long as it takes; a wait on a record change is capped at a year as a safety net, and a wait that expires on that cap never continues as if the change had arrived.

Use “run the steps below anyway” for escalation (“if the task is not done in three days, mail the manager and carry on”) and “stop the rule” for offers that expire.

One wait, or a branch per record

A wait that watches several records normally releases once, when they have all changed. Switch it to a separate branch per record and the rule opens one branch per matching record instead, each running the steps you put inside it against that record. Ten tasks, ten branches, each chasing its own assignee. The join step is how you gather them again. Branches can nest up to three levels deep.

Pending tasks: the process is visible from day one

When a rule suspends on a wait, the Create task steps below the wait are not postponed invisibly. The tasks are created immediately as pending: they show up on the record with everything filled in, so everyone can see the whole process ahead. A pending task cannot be edited or completed until its gate releases, its assignee is only notified at activation, and its SLA clock starts at activation too.

Two consequences worth knowing:

Deleting a pending task is the escape hatch. If a plan changes, delete the pending task; anything that depended on it is dropped with it rather than activating below a broken chain.
The rule you see may not be the rule that runs. A suspended execution carries a frozen snapshot of its remaining steps, so editing or deleting the rule never changes a process already in flight. The run history names the version that actually ran.

Ladders: only run the first matching action

The rule setting Only run the first matching action turns the steps into a ladder: the first step whose conditions match runs, the rest are skipped. That is the natural shape for tiered outcomes, such as a cancellation fee that is free more than a week out, 50% within a week and 100% within 48 hours: three Set price steps, each with a narrower condition, ordered narrowest first.

A ladder picks one path and ends, so it cannot contain waits or condition gates; the form tells you so if you try. If you need a tiered outcome inside a longer process, put the ladder in its own rule.

How rules interact

Every matching rule runs

Rules on the same entity run in list order, and there is no first-match-wins across rules. Two rules writing the same field both write it; the later one wins.

Later rules see earlier writes

Within one event, a rule lower in the list sees the values an earlier rule just set. Compare values (equals) rather than changes there: the "changed to" operators describe the user's save, not another rule's write.

Watched fields are checked against the user's save

A rule watching only the assignee field does not wake up when another rule sets the assignee during the same event. For rules meant to chain, leave the watched fields broad, or better:

Prefer one rule over a chain of rules

Steps in one rule run in a guaranteed order against the same record, each with its own conditions. A chain of separate rules has none of those guarantees. Reach for multiple rules when triggers differ, not to sequence work.

There are also engine-wide safety nets you will rarely meet but should know exist: a cap on how many rules one event may execute, a cap on how many runs one record may cause per day, and a circuit breaker that deactivates a rule that keeps failing. A rule acting on its own record does not retrigger itself, and cross-record effects cascade only a few levels deep, so two rules pointing at each other cannot loop forever.

Reading a process in the run history

A multi-step rule writes more interesting history than a simple one. The run that hits a wait records the steps below it as skipped with the reason waiting; every release writes its own run, so one process can span several runs over weeks. The reasons tell you exactly where a process stands:

Reason	Meaning
Waiting	The wait is armed; the steps below run later.
Deferred	The step runs when the wait above it releases.
Task already created as pending	The ghost task exists on the record and activates when its gate releases.
Halted by an earlier condition step	A condition gate above it did not match, so this step was skipped.
Conditions not met	The step's own conditions did not match this record.

The dry run understands flows too: it shows which steps would run now, which tasks would be created as pending and where the rule would suspend, without touching the record.

← Automations Next: Automation use cases→