Understand automation runs and repeat safety
Understand how permissions, step results, iteration, and run history support safe automation.
One trigger creates one workflow run. The run reads workflow steps in order. It keeps each step result so a later step can reference it.
Run permissions
A workflow runs inside its organization scope and with permissions derived from its owner. A known feature still fails when the runner lacks permission. Related rows keep the same data scope.
Selection and iteration
A list step provides its results as rows. An each value of ${steps.find.rows} runs the
next feature once for each row. A safety limit prevents unlimited iteration in one step.
Remove processed rows from the query
A repeated automation must remove processed rows from its next query.
| Query condition | Action result | Next query |
|---|---|---|
status = confirmed | status = no_show | Does not select the row again. |
status = open | status = closed | Does not select the row again. |
ends_at < now AND status = active | status = archived | Does not select the row again. |
An external delivery feature needs a duplicate-prevention key or processed state when it cannot change the selection condition. Check repeat safety in the feature description.
Failures and another run
The workflow run and each step record status and errors. Before another activation, inspect which changes completed. A query that excludes completed rows lets the next run process the remaining rows.
Operating checks
- Review the query and row limit before activation.
- Use one test row for the first run.
- Inspect step inputs, results, and errors in run history.
- Run the same condition again and confirm that changes are not duplicated.
- Deactivate the workflow first when a result is unexpected.
Use Verified automation recipes for complete examples.