On this page
Most automation starts as a script. Someone notices a repetitive task, writes a few lines to handle it, and schedules it to run. That is often the right first step. The problem comes later, when there are dozens of such scripts, each with its own assumptions, and the organisation depends on all of them without being able to see how they behave.
At that point automation has become infrastructure in practice. It deserves to be designed like infrastructure too.
The anatomy of an automated workflow
A reliable automated workflow usually has the same parts, whether it publishes content, processes invoices or synchronises records between systems:
- Trigger — what starts the work.
- Validation — whether the input is acceptable.
- State — where the workflow is and what it has done.
- Business rules — what should happen given the input and state.
- Approval — whether a person must decide before execution.
- Execution — the action with an external effect.
- Retries — what happens when execution fails.
- Audit — the record of what happened and why.
- Monitoring — how anyone knows it is working.
A script typically implements the trigger, some business rules and the execution, and leaves the rest implicit. The missing parts are where most automation failures come from.
Triggers
Triggers can be time-based, event-based or manual. Each has failure modes. Scheduled jobs miss runs when the machine is down. Event triggers receive duplicates or arrive out of order. Manual triggers get pressed twice.
Designing triggers as infrastructure means deciding what happens in each of these cases: whether a missed run is caught up or skipped, how duplicate events are recognised, and whether starting the same workflow twice is safe.
Validation
Automation amplifies bad input. A person processing a malformed record will usually notice something is wrong; a script will process it exactly as written, possibly many times.
Validating input at the start of the workflow — required fields, formats, ranges, references to records that actually exist — turns silent corruption into a visible, handled failure.
State
Scripts usually keep state in memory or not at all. If they stop halfway, nobody knows which steps completed. Durable workflows record their state as they go: received, validated, awaiting approval, executing, done, failed.
Persisted state makes several things possible. A workflow can resume after a restart instead of starting over. Two runs can be prevented from acting on the same item. And people can see, at any moment, what the automation is doing.
Business rules
Rules that decide what a workflow does should be explicit and in one place. When they are scattered across scripts, changing a policy means finding every script that encodes it, and it is easy to miss one.
Deterministic rules should stay deterministic. If an AI model is used to draft, classify or extract, its output should feed into rules rather than replace them. Scheduling, permissions, limits and state transitions are not good candidates for improvisation.
Approval
Some actions should not run without a person's decision. Where that applies, the approval should be a defined step in the workflow with its own state, not an informal message in a chat channel. The person should approve a specific revision of what will be executed, and execution should use exactly that revision.
Execution
Execution is where the workflow touches the outside world: sending, publishing, paying, writing. It is the part that is hardest to undo, so it benefits from the most care.
Two properties matter most. Execution should be idempotent where possible, so that repeating it does no additional harm. And it should record its result, so that the workflow knows whether the external effect happened.
Retries
Failures are normal: networks drop, services rate-limit, credentials expire. A workflow needs a policy for each kind of failure — retry with backoff, wait for a person, or stop.
Retries are only safe when execution is idempotent or guarded. Retrying a non-idempotent action without checking whether it already happened is one of the most common causes of duplicate messages and duplicate charges. After a bounded number of attempts, the workflow should stop in a visible failed state rather than retrying forever.
Audit
An audit record answers the questions that matter after the fact: what triggered this run, what input it saw, which rules applied, who approved what, what was executed and with what result. It is essential for incidents and useful every day, because it shows whether the automation is doing what people believe it is doing.
Monitoring
Automation that fails silently is worse than no automation, because people stop checking the work it was supposed to do. Monitoring should cover not only errors but absence: a daily job that did not run, a queue that stopped draining, an approval that has waited far longer than usual.
When a script is enough
Not every task needs all of this. A one-off data fix or a personal convenience script does not need durable state and an audit trail. The shift should happen when a workflow becomes something other people rely on, when its actions are hard to reverse, or when it runs often enough that its failures would go unnoticed.
Conclusion
Treating automation as infrastructure is less about adding tools than about making implicit behaviour explicit. Triggers that handle duplicates, validation that rejects bad input, state that survives restarts, rules in one place, approvals where they matter, careful execution, bounded retries, a clear audit record and monitoring for absence — these are what turn a collection of scripts into a system people can trust.
- automation
- workflows
- reliability