Most automation is a service account with more access than anyone on the team, running scripts nobody reviews. It is the most privileged actor in the workspace and the least watched one.
A workflow is a credential
Every workflow is bound to an agent access. What a step may do is that access’s scopes intersected with its author’s current permissions — so a workflow can never reach further than the person who wrote it, and demoting the author narrows the workflow too.
Stopping for a person
A manual.approval step pauses the run until someone approves or rejects it. Approval of a whole plan is tied to a hash of the graph, sub-workflows included — edit anything and it asks again. A step marked destructive must have no retries, a note on its blast radius and an approval in front of it, or the workflow doesn’t save.
Resume, don’t repeat
Runs are leased: a worker holds a run while it works on it, and if that worker dies another one picks the run up. Steps that already succeeded are reloaded rather than run again. A server command or task that was already sent is adopted instead of sent a second time, and an HTTP request carries an idempotency key so the service on the other end can do the same.
trigger every 15 min
host.metrics disk 89.4%
condition disk > 85
manual.approval waiting for you
server.exec vacuumdbHonest about the edges
A webhook is authenticated by the random token in its URL — anyone holding the URL can start a run, so treat it as a secret and rotate it if it leaks. A guardrail that requires approval refuses the step outright, because nobody is sitting in front of an unattended run to approve it. Finished runs are kept for thirty days.
Start from something that works
109 templates cover monitoring, incidents, databases, Kubernetes, storage, CI/CD and security. Or describe the workflow in a sentence and Runa draws the graph on the canvas, checked by the same validator as a save.