October 13, 2026
Automation has an appealing promise: set it up once, then forget it. In practice, the forgetting part is where things go wrong. A workflow that quietly duplicates records, fires forty notifications a day, or breaks on the first customer with an apostrophe in their surname does not save time. It borrows time from next month and charges interest.
The pattern is consistent. The mistakes that cost the most are rarely technical. They are design decisions made in a hurry by someone who was already busy, and they tend to look sensible until the third month of operation. What follows are the seven you will meet most often, plus what to do instead.
1. Over-triggering: automating anything that moves
The most common failure is a trigger set too wide. Someone builds a notification for every new support ticket, every row added to a sheet, every form submission. Within a week the channel is a wall of noise and people start scrolling past it, which means the one alert that mattered got missed along with the other thirty.
A useful filter before you automate anything: how often does this task actually happen, and how long does it take by hand? If it runs twice a month and takes three minutes, a workflow with its own maintenance overhead is a net loss. Automate the daily grind, not the occasional errand.
When an alert does earn its place, make it earn it properly. Batch low-urgency updates into a daily digest. Add a threshold so the workflow only speaks up when a number crosses a line rather than every time it moves. Route different severities to different channels, so the on-call channel stays quiet enough to be trusted.
2. Silent failures and no error handling
An automation that fails loudly is a nuisance. One that fails silently is a liability. The classic version: a workflow syncs form entries into a CRM, hits one record with an unusual character, stops, and nobody notices for eleven days. By then the sales team has been calling leads who never made it into the system.
Build for failure from the start:
- Decide what happens on a failed step: retry a set number of times with a delay, then stop and alert.
- Send the failure somewhere a human reads. A log nobody opens is not monitoring.
- Keep a copy of the payload that failed, so you can replay it after fixing the cause.
- Set a fallback for partial success, rather than leaving records half-written.
Also test the ugly cases deliberately: empty fields, missing attachments, duplicate submissions, a name with an accent, a date in a different format. Every one of those is a real customer, and each one is cheaper to handle before launch than after.
3. Nobody owns the automation
Six months in, the person who built the workflow has changed teams. The tool still runs. Then it breaks, and the search begins: who has admin access, where do the credentials live, why does this step map to that field? Half a day disappears before anyone has fixed a thing.
Ownership needs to be explicit and recorded in the tool itself, not in someone's memory. Put a named owner and a backup in the workflow description. Write three lines explaining what it does and what it depends on. Store credentials somewhere shared and documented rather than in a personal account. Keep a simple inventory of every live automation, what it touches, and when it was last reviewed.
This is unglamorous work, and it is the difference between an automation that survives staff changes and one that becomes folklore.
4. Automating a process nobody has mapped
There is a particular kind of disappointment that comes from automating a messy process and getting a faster mess. If two teams disagree about who approves a refund, a workflow will simply encode the disagreement and replay it at scale.
Run the process by hand a few times first and write down what actually happens, including the exceptions. You will usually find that the documented process and the real one have drifted apart. Fix the obvious friction, delete the steps that exist only because of an old workaround, then automate what remains. Paving a cow path just gives you a smoother cow path.
5. Brittle builds: hardcoded values and fragile steps
Automations break for boring reasons. A hardcoded email address belongs to someone who left. A step relies on a browser click on a button whose label changed. A date is written as a fixed string rather than calculated. A file is read from someone's desktop folder.
Use configuration for anything that might change: recipients, thresholds, folder paths, environment names. Prefer stable identifiers over screen positions and display text. Where you must rely on something fragile, add a check that fails early with a clear message, so the workflow tells you what broke instead of what it could not do.
6. No logging, so nobody can answer “did it run?”
When a colleague asks whether the invoice export ran last night, the answer should take ten seconds. If it takes an investigation, the automation is a black box and people will start doing the task manually anyway, just to be sure.
Log the basics on every run: timestamp, records processed, records skipped, duration, outcome. Keep it somewhere searchable and readable by someone who did not build the workflow. Add a plain summary where you can, such as a single daily message reporting what happened. Visibility builds trust, and trust is what stops the duplicate manual work that automation was meant to remove.
7. Set-and-forget: no review, no retirement
Automations accumulate the way tabs do. A workflow built for a one-off migration keeps running long after the migration. A daily report nobody opens still sends, and someone occasionally spends twenty minutes checking it because it exists.
Put a review date on every automation when you create it, and diarise a light quarterly pass. Ask three questions: is it still running, is it still needed, and is it still correct? Retire what has outlived its purpose. Deleting a workflow is a legitimate maintenance task, not a failure.
A five-minute check before your next automation
Before you build, run through this quickly. It catches most of the problems above while they are still cheap to fix.
- Write one sentence describing the outcome and who benefits.
- Confirm the task happens often enough to be worth automating.
- Name the owner, the backup, and where the documentation lives.
- List the three most likely failure points and what should happen at each.
- Decide where alerts go and who reads them.
- Set a review date before you switch it on.
None of this takes long. And the reward is the thing automation is supposed to deliver: work that runs quietly in the background, with a small number of people who know exactly how it behaves when it does not.
