Field guide 03
Automation governance from trigger to recovery
A practical operating model for workflow design, credentials, human approval, error handling, monitoring, change control and recovery.
01Selection
Choose a stable process with a recognisable outcome
Good candidates have repeated inputs, explicit decisions, measurable outputs and an affordable review path. Volume alone is not a reason to automate ambiguity.
- Map the current process and exceptions
- Define a correct result
- Calculate the cost of review and failure
- Name the process owner
- Decide what remains human
02Design
Treat the workflow as a contract
Record its trigger, inputs, source systems, transformations, outputs, permissions and timing before selecting the implementation tool.
- Trigger and eligibility rule
- Input schema and validation
- Direction of truth
- Output and side effects
- Timeout and completion criteria
03Reliability
Build the failure path before celebrating the happy path
Retries, duplicate delivery, unavailable systems, malformed data and partial completion are normal production conditions and need explicit behaviour.
- Bounded retry with back-off
- Idempotency and duplicate protection
- Dead-letter or recovery queue
- Compensating action for partial failure
- Alert containing useful recovery context
04Control
Put human approval where consequence changes
A review step is most useful before an external message, financial action, record deletion, permission change or low-confidence automated decision.
- Review threshold written down
- Reviewer receives evidence and context
- Approval and rejection are recorded
- Timeout escalates to a named deputy
- Override feeds improvement
05Security
Credentials belong to the system, not an individual
Connections should use the minimum necessary access, live in approved secret storage, rotate on a schedule and have a responsible owner.
- Service identity where supported
- Least-privilege scopes
- Separate environments and credentials
- Rotation and removal procedure
- Access review after team changes
06Monitoring
Measure the workflow as an operating service
Successful execution is not enough. Monitor volume, latency, failure, retries, exception backlog, cost and the business outcome the automation is meant to support.
- Execution success and failure
- Time to completion
- Exception and replay backlog
- Cost per useful outcome
- Alerts tested with the owner
07Change control
Keep changes reversible and recovery practised
Automation should have version notes, representative tests, a release owner, a rollback route and a runbook somebody else can follow.
- Workflow and integration register
- Test cases based on real exceptions
- Controlled release and rollback
- Runbook and owner details
- Retirement review for unused logic
Related