What is workflow automation, and where does it go wrong?
Software that performs a sequence of routine steps that people previously did by hand — moving data between systems, sending notifications, creating records, routing approvals — and it fails in patterns predictable enough to plan around.
The forms it takes:
Integration platforms, connecting applications through their interfaces — the sound approach where the systems support it.
Robotic process automation, where software drives the user interface of an application by clicking and typing as a person would. Used where no interface exists, and inherently fragile, because it breaks whenever the screen layout changes.
Built-in workflow inside a platform you already use, which is frequently the most robust option and the most overlooked.
Scripts, which are powerful, cheap and frequently undocumented.
Where it goes wrong:
Automating a bad process. The most expensive mistake. Automation makes a broken process run faster and more consistently wrong. Fix or simplify first, then automate, and frequently the simplification removes the need.
No error handling. The path where everything works is easy; the value is in what happens when a system is down, data is malformed or a step half-completes. Silent failure is the usual outcome, and nobody notices until the damage has accumulated.
No ownership. The person who built it leaves, and it keeps running until it does not, with nobody able to fix it.
Brittleness to change. An upgrade alters a field name or a screen, and the automation fails or, worse, writes wrong data.
Invisible dependencies, where a business-critical process turns out to rest on an unmonitored script on someone's account.
Credentials embedded in the automation, which is a security problem and an access-control one.
Over-automation, where edge cases are forced into a rigid flow and staff spend more time working around it than the manual process took.
What good practice looks like: document what it does and who owns it; monitor and alert on failure rather than success; design for the exception path; use service accounts rather than personal credentials; keep a manual fallback for anything critical; and measure whether it actually saved time, which is remarkably rarely checked.