A meaningful share of our work is inheriting automations someone else built — often by a freelancer who has moved on, sometimes by an enthusiastic employee who has left. The failure patterns are remarkably consistent.
1. No error handling
The workflow assumes every API call succeeds. When one doesn't, the run stops silently and nobody notices for days. Every workflow needs an error branch, and every error branch needs to alert a human somewhere they'll actually see it.
2. No idempotency
A retry re-sends the message or re-creates the record. Any workflow that writes data needs a way to recognise it has already processed a given event — an external ID check, a processed flag, something.
3. Credentials owned by one person
Integrations authenticated with an individual's account break the day that person leaves or changes their password. Use service accounts, and store credentials somewhere the business controls.
4. No documentation
A workflow with twenty untitled nodes is unmaintainable by anyone but its author, and often by its author six months later. Name your nodes. Write down what the workflow does and what it assumes.
5. Automating a broken process
If the manual process is confused, automating it produces confusion faster and at greater scale. Fix the process first; the automation is the last step, not the first.
6. No monitoring
Nobody is watching whether workflows are running. The first sign of failure is a customer complaint. Execution monitoring with failure alerting costs almost nothing and changes this entirely.
7. Over-automation
Some things shouldn't be automated: decisions that change every time, actions that are expensive to reverse, processes that run twice a month. A checklist is sometimes the correct answer, and knowing when to stop is part of doing this well.
If you're inheriting automations from someone who has left, start with an audit. You can't maintain what nobody has documented.