A fault is part of the process
Treating errors as rare technical interruptions creates automation that looks complete on a diagram but fails opaquely in production. External dependencies, configuration drift, permissions and incomplete data all create normal failure states.
Design the recovery path at the same time as the happy path. Decide what must remain unchanged, who should know and what evidence they need.
Capture enough context, not every field
A useful audit event is structured for diagnosis and deliberately small.
- A correlation ID shared across the process.
- The automation source, step and safe error category.
- The affected record reference and recovery state.
- A timestamp and ownership path without sensitive payloads.
Avoid the recursive rescue
A reusable logging subflow should not update the same business record in a way that re-enters the failing automation. Keep diagnostic storage separate, make writes idempotent where retries are possible and define what happens when logging itself fails.
Make recovery explicit
Not every failure should retry. Configuration errors need an owner; transient integration errors may need a bounded retry; invalid input should return to the person who can correct it. The fault path should express that decision instead of ending at an email alert.