How a Workflow runs
Each Workflow runs as an Action, step by step, under its Roles' Permissions, and retries, escalates or undoes a step that fails.
Each time a Trigger fires, its Workflow runs as one Action, step by step, and the record is kept forever. A deploy or a crash never loses a finished step: the Action resumes at the next one.
One Action, start to finish
Dunning runs every day for the Billing Specialist. Each run is one Action with four steps:
- Retry.
Invoice.collectcharges each unpaid Invoice again. The seat's dunning Mandate covers it, so no one is asked. - Tell.
Message.createwrites to the Customer once per retry, with a link to update the card. - Pause. When the last attempt fails,
Subscription.pausestops access. The step names its undo,Subscription.resume. - Write off. Thirty days after service pauses unpaid,
Invoice.voidcloses the Invoice.
When the card has expired, no retry can succeed, so the Action skips straight to step 2. The rest of the chapter explains each rule that run follows.
What a step does
A step calls one Verb as one Role. It runs under that Role's Permissions and Limits, whether an agent or a person fills the seat. The Verb decides whether the step waits:
| The Verb is | The step |
|---|---|
| Two-way, inside the Role's Limits | runs at once |
| Granted by a Mandate the Role holds | runs, and waits out the Verb's delay window first if it is one-way |
| Past a Limit | waits on an Approval from the accountable Role or the Founder |
Each step has a stable id, so an Action resumes on the right step. Every Process page shows who does each step.
When a step fails
A failed step retries first. When retries run out, the step does what it declares:
| On failure | What happens |
|---|---|
retry | Tries again with backoff; the default |
escalate | Hands the step to a named Role as a Task |
compensate | Calls the step's undo Verb, such as Subscription.resume after a pause |
fail | Ends the Action failed, with the reason on record |
A step can also name exceptions: known outcomes that leave the happy path and continue at a later step, as Dunning's expired card does. A timeout caps how long a step waits before its failure rule applies.
On time
A Process can promise a service level: a target time, a business-hours or calendar clock, and the Role that hears when an Action runs late. Waiting on someone outside, such as awaitingInput, can stop the clock.
Support promises a first answer within one business hour, and the clock stops while it waits on the Customer. Privacy promises 30 calendar days.
Turn a Process on, change it, pause it
A Process is off, on or paused. Each Product Template turns its Processes on when the Startup is created. The rest wait for Process.enable or for the Event that wakes them, such as the first Bill waking Payables.
Process.pause stops new Actions, and Actions already running finish. Each Process lists its Settings, each with the sentence that changes it and the call it makes. A changed Setting applies to the next Action, never to one already running.
What an Action records
An Action is pending while it runs, with a reason such as awaitingInput or awaitingTime, then ends done, failed, canceled or refused. It keeps every step's input, output, Role, cost and Events.
Action.retry, Action.pause, Action.resume and Action.cancel steer one that is running. Canceling runs the compensation of every step that declared one.
To write a Workflow of your own, see Workflow files, or ask your agent for one: automate a workflow.
Next
Part 4 of six chapters on how the business works. Each step runs on a System, and how to read a System page is next.