Chapter 1 of 13
Start with one process people already run
Choose work that currently lives in email, a spreadsheet or a script nobody wants to touch. Keep the first branch and human decision real.
- Actions inside a step run in order; later actions and steps can use earlier output.
- A malformed condition refuses to match instead of guessing.
- Loops link back to an earlier step and must carry a re-entry cap.
Chapter 2 of 13
Build your first workflow
Draw the path, make exceptions explicit and validate every outcome before publishing.
- 01
Place the steps
Add service calls, a human task or a wait. Set timeouts and priorities where the process requires them.
- 02
Connect the path
Order conditional links deliberately and keep one default route for the case that needs it.
- 03
Validate
Fix unreachable steps, paths that never terminate, missing required configuration and human decisions whose outcomes lead nowhere.
- 04
Publish
Freeze a version. Runs already in flight stay on the version they started with while the draft remains editable.
Chapter 3 of 13
Put a human decision where it belongs
A task pauses the run, appears in an inbox and selects the outgoing path through a decision your business names.
- Assign one person, a role, a named list, a quorum, a weighted vote, any-of or all-of.
- Define real outcomes and reason codes instead of forcing every process into approve/reject.
- Use leased claims so an abandoned task returns to the queue automatically.
- Add deadline warnings, escalation and an optional record lock while review is active.
- Require re-authentication and a reason for decisions that need a stronger signature trail.
- 01
Enable task reminder emails
Open the human-task settings on a step and enable email reminders. Set how many hours after task creation it becomes due, then choose how early the due-soon email should arrive.
- 02
Choose repetition
Send one due-soon email or repeat it at your chosen interval. Enable overdue emails and set their repeat interval while the task remains open.
- 03
Keep time to act
Expiration closes the task. Set expiration later than the due target, or leave it blank, if people should continue receiving overdue reminders and completing the task.
- 04
Publish and test
Publish the workflow settings and start a new test run. Existing tasks retain the settings captured when they were created.
Chapter 4 of 13
Arm the trigger
A binding connects a published workflow to a record event, signed request, schedule or manual/API start.
- 01
Choose the trigger
Use a record change, signed HTTPS request, cron/fixed/one-time schedule, portal action or scoped client key.
- 02
Map the input
Complete the values the first step needs and add a filter when only some events should start work.
- 03
Arm the binding
The trigger will not fire until mappings compile successfully. This prevents half-configured work from starting.
Chapter 5 of 13
Connect an external system
Choose an available external system and activity, connect the account it should use, then map inputs from the trigger or earlier steps.
- 01
Choose a system
Use a supplied External System when available. For a custom API, register its base URL, authentication, retry policy and throttling.
- 02
Select an activity
Use a supplied activity. For a custom system, import useful operations from its API description or define the missing operation.
- 03
Select the account
Connect and name your account inside the External System, then choose the account connection for each activity. The Integrations guide explains account setup and permission checks.
- 04
Map fields
Use trigger values, earlier output, signals, fixed values, templates or computed values. Review the resolved mapping before arming.
Chapter 6 of 13
Map data through the run
Every action declares the values it needs. Resolve them from known run data, then decide explicitly where useful output should go.
| Source | Use it for |
|---|---|
| Trigger input | Values supplied by the event, schedule, portal action or client call that started the run. |
| Earlier output | A response or calculated value produced by a previous action. |
| Current record | The latest state of the record, read at the point the step runs. |
| Signal | Information delivered after the run started. |
| Fixed or computed value | Constants, templates and expressions owned by the workflow. |
- Map useful action output back onto the record when it belongs in the business history.
- Start with catalog defaults, then use workflow input and output overrides for the relevant record type. These overrides leave protected definitions intact.
- Review the resolved mapping rather than reading three layers of configuration separately.
- Mappings compile when the trigger is armed, so the checked mapping is the one the run uses.
Chapter 7 of 13
Handle slow and waiting work
Waiting is a first-class run state. Park the run until the expected answer arrives instead of keeping a worker or connection open.
| Wait type | Resume it with |
|---|---|
| Human decision | A valid outcome submitted from the assigned task. |
| External service | An authenticated callback carrying the result. |
| Business signal | A named signal sent to the waiting run. |
| Scheduled time | The configured deadline or wake-up time. |
- 01
Hand off the work
Start the slow operation and keep the external job reference with the step.
- 02
Park with a deadline
The run stores its state and consumes no worker while it waits. A deadline prevents an indefinite wait.
- 03
Authenticate the answer
The callback uses a token issued for that run; a generic unauthenticated request cannot resume it.
- 04
Continue from recorded output
Store the result on the step, then let the next mapping use it like any other earlier output.
Chapter 8 of 13
Protect connected systems live
Control pressure at the boundary that needs protection. These controls change runtime behavior without editing and republishing the workflow.
| Control | Scope |
|---|---|
| Pause or resume | One connected system or one action. |
| Stop | Prevent new calls at the selected system or action boundary. |
| Call-rate limit | Requests dispatched over time for one action. |
| Concurrency limit | Calls or workflow runs allowed at once. |
| Emergency disable | Every external integration when containment matters more than throughput. |
- Set maximum run duration and payload size as workload guardrails.
- A rate-limited step waits and retries without spending a failure retry attempt.
- Use the live throttling view to confirm what is paused or constrained before changing a workflow.
Chapter 9 of 13
Operate workflow runs
Every run records its inputs, outputs, errors and chosen path. Recovery has specific verbs instead of one generic retry button.
| Action | Use it when |
|---|---|
| Restart a step | The cause of one failed step is fixed. |
| Rewind | The run must return to an earlier step; later work becomes superseded. |
| Replay | The whole run should execute again with the same input and its own record. |
| Signal | A waiting run has received the information it needs. |
| Cancel | The work should stop. |
- Pause or resume a connected system or one action without deploying.
- Override concurrency and call-rate limits when an integration needs protection.
- Notify on failure, completion, timeout, a stalled run or a failure-rate threshold.
- Write every action to tolerate retry; execution is at least once.
Chapter 10 of 13
Embed Automation in your product
Keep the operational experience inside the product your users already know. Use the ready-made surfaces and event stream instead of rebuilding workflow state from guesses.
- Embed the task inbox and decision panel so people review work without leaving your product.
- Show the run timeline and current-state badge beside the record the work is about.
- Add a follow toggle for progress notifications and a start control where a manual run belongs.
- Use workflow-scoped API keys for programmatic starts, and rotate each consumer independently.
- Subscribe only to the supported runtime events: workflow started/completed/failed; task created/assigned/completed/signed; step completed/failed; and external call completed.
Chapter 11 of 13
Worked example: invoice approval
React to the invoice created in Data, choose exactly one route, make the ERP write duplicate-safe and recover from a transient failure without replaying completed work.
Source event entity.created
Record invoice / payables / v1
Filter status == received
Subject event data record guid
Workflow input invoice_guid <- subject.id| Step | Behavior and route |
|---|---|
| 1 · Read invoice | Read the current Data record by invoice_guid so the decision does not rely on a stale trigger payload. |
| 2 · Choose review path | If total is below 1,000, take the default auto-approval path. Otherwise create a Finance review task. |
| 3 · Finance decision | approved continues to ERP posting; rejected updates Data to rejected and ends. Every allowed outcome has a route. |
| 4 · Create ERP payable | Call the registered ERP action once the invoice is approved. Map only the operation’s declared inputs. |
| 5 · Record completion | Update the Data record to posted with the ERP reference, then complete the run. |
POST /payables
body.reference <- record.invoice_number
body.supplier_code <- record.supplier_code
body.amount <- record.total
body.currency <- record.currency
body.source_guid <- record.guid
Idempotency-Key <- erp-payable:{record.guid}:v1
step.erp_reference <- response.payable_id| Observed run history | Operator response |
|---|---|
| Data trigger accepted; invoice read completed | No action needed. The run is using the published workflow version captured at start. |
| Finance task waiting | An assigned reviewer claims the task and submits approved or rejected. Waiting consumes no worker. |
| ERP action failed with a transient 503 | Fix or wait for the ERP boundary, then Restart the failed ERP step. Completed read and approval work stays recorded. |
| ERP retry reports the same payable | The destination idempotency key made the repeated call safe; store the returned payable id and continue. |
| Data update completed; run completed | Correlate the run id, invoice guid and ERP payable id in support and audit records. |
Chapter 12 of 13
Troubleshoot why a run did not move
Start with the run state and the exact step. The history normally tells you whether the run never started, is deliberately waiting, or failed while doing work.
| Symptom | Check first |
|---|---|
| The trigger never starts a run | Confirm the workflow version is published, the binding is armed and its filter matches the incoming subject. |
| Arming is refused | Complete every required input mapping and fix any mapping that cannot compile. |
| The run stops after a conditional step | No link may have matched. Check link order, malformed conditions and whether a default path exists. |
| A human task appears stuck | Check assignment, claim lease, deadline and whether every allowed outcome has an outgoing link. |
| An external call keeps waiting | Confirm the callback used the token for this run and arrived before the deadline. |
| A call is not being dispatched | Check whether the system or action is paused, stopped, rate-limited or at its concurrency ceiling. |
| A recovery repeats an external side effect | The action needs an idempotency key or another duplicate-safe contract. |
Chapter 13 of 13
Know the current boundaries
Design against what exists today, not a workflow feature that sounds adjacent.
- No parallel branching, fan-out or wait-all joins: one path leaves each step.
- No sub-workflows or nested workflows.
- No built-in scripting step; scripting-shaped work belongs in a connector action or assistant tool.
- No file import/export for workflows; published templates are the reusable unit.
- Run restart, rewind and replay exist; a separate workflow-event replay console does not.
Continue
See how the other product fits
Data and Automation are sold separately and work independently. Use both when a workflow should read or change a versioned business record.