THE SHORT ANSWER
Automation fails when triggers, data, rules, permissions, integrations or monitoring no longer match reality. Reliable workflows prevent duplicates and loops, validate inputs, limit access, expose failures, support safe retries and assign an owner for maintenance.
Expect technical and business failure
| Failure | Control |
|---|---|
| Wrong trigger | Validate event and eligibility |
| Duplicate execution | Idempotency or duplicate check |
| Bad data | Schema and business validation |
| Broken integration | Retry limit, alert and recovery queue |
| Infinite loop | Action limits and loop detection |
| Missing permission | Least privilege and access monitoring |
| Silent failure | Outcome reconciliation and owned alert |
| Stale logic | Review dates and change ownership |
| Vendor dependency | Fallback and export path |
| Over-automation | Human escalation and customer override |
Limit what a failure can affect
Protect credentials, minimize shared data, separate environments where appropriate and audit important actions. Permissions should follow the workflow task, not the maximum the connector offers.
Evidence & context: OWASP Foundation · OWASP Foundation
Give every automation an owner
- Document purpose, dependencies and rules.
- Monitor successful outcomes, not only successful runs.
- Test changes and representative exceptions.
- Review permissions and data use.
- Maintain a pause and recovery procedure.
- Retire workflows that no longer create value.
Apply the idea to one real workflow
Choose one current workflow. Record the present outcome, the proposed change, the accountable owner, the most important exception or failure, and one before-and-after measure. Test the smallest safe version before expanding it.
Sources & further reading
- Quality assurance: testing your service regularly
GOV.UK Service Manual. Government guidance on usability, functional, performance, security, accessibility and continuous testing. It does not prescribe one universal test suite.
- Authorization Cheat Sheet
OWASP Foundation. Security guidance emphasizing least privilege, deny-by-default behavior and authorization checks on every request. Implementation details depend on the application's threat model.
- Secrets Management Cheat Sheet
OWASP Foundation. Security guidance on secret creation, storage, distribution, rotation and revocation. It supports the principle that private credentials do not belong in public client code.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗