Why process automation breaks

An automation project is often declared a success when a notification starts going out on its own. Weeks later the same work lands in someone’s inbox as an exception. The flow did not stop. It had an undefined branch.

That is exactly the operational flow diagnosis: automation built before sequence, trigger, and exception path are written hides personal follow-up rather than replacing it.

The happy-path trap

The happy path is the scenario in which every record follows the expected sequence. Real operations run on exceptions: a missing document, conflicting stock, an unauthorized approval, a delayed third system. If those are left outside as ‘we’ll look later’, the automation only works on quiet days.

• Who receives the exception, and how long does it stay there?
• Which state does a timeout move the record into?
• How many times is a retry attempted, and in whose name?

A trigger is not enough without a rule

When a step runs cannot be separated from the rule that makes that step legitimate. If the business rule still lives with a person, automation encodes that person’s habit. When the person changes, ‘the system broke’ is the complaint. The system did not break. The rule was never written.

Process automation is built only when state, trigger, and exception sit in the same model. Otherwise it is a pile of timers and email.

What is defined, then what is automated

Steps are named first. Each step gets an entry condition, an exit state, and the record it owns. What is automatic is separated from what needs a human decision. The human decision is also a state in the system, not a chat message.

In most operations that definition needs a custom software layer, because packaged tools centre the happy path. The exception is squeezed onto the edge of the product.

If it is known at which step the broken flow returns to a person, speculation about automation can stop. Write that step.