What Happens When an Automation Breaks?

An automation can save hours of repetitive work. A broken automation can quietly create hours of new problems. That is why a reliable automation is not just a chain of successful steps. It also needs a plan for failure.

What can cause an automation to break?

• passwords or permissions changing;
• an account being disconnected;
• an API or third-party service changing;
• a spreadsheet column being renamed or deleted;
• a form being edited;
• unexpected or missing data;
• duplicate records;
• a payment or booking service becoming unavailable;
• a usage limit being reached;
• an AI step returning something the next step cannot handle;
• the automation platform itself having an outage.

Failures are normal operational events. The system should be designed with that expectation.

The worst type of failure: silent failure

Imagine an automation that should add every website enquiry to a lead register. It stops working on Tuesday. The website still works and customers still submit forms. Staff assume the register is current. By Friday, several enquiries are sitting somewhere nobody checks.

A visible error can be fixed. A silent error can become a business problem before anybody knows it exists.

What should monitoring actually check?

• Did the automation run when expected?
• Did it finish successfully?
• Was the required record created?
• Is important information missing?
• Has a workflow been stuck too long?
• Did an external service return an error?
• Did a message fail to send?
• Did an AI step produce incomplete output?
• Has an account permission expired?

Monitoring should focus attention on failures that need action, not generate noise.

What should happen when something fails?

1. Detect the error.
2. Log enough information to investigate.
3. Mark the affected record clearly.
4. Alert the appropriate person.
5. Stop unsafe downstream steps.
6. Allow the record to be retried or handled manually.
7. Continue or close cleanly once resolved.

Errors vs exceptions

A technical error might be an unavailable calendar API or expired permission. A business exception might be a missing delivery date, unusual customer request or a price needing manager approval.

Good automation needs a route for both: technical errors need repair; business exceptions need a defined human process.

Why validation matters

A stronger workflow checks required conditions before work moves forward. An order should not be marked “Ready” when required information, approval or payment state is missing.

This is where automation becomes more than convenience: it can enforce the process itself.

What happens when a spreadsheet changes?

If an automation expects a field called “Customer Email” and somebody renames it, the workflow may stop finding what it needs. Protected structure, clear ownership, validation and change testing can reduce that risk.

The lesson is not “never use spreadsheets”. It is to treat an operational spreadsheet like part of a system, not an informal scratchpad.

What happens when permissions expire?

Connections to email, calendars and CRMs often rely on authorised accounts. Permissions can expire or be revoked when passwords change or staff leave. A robust system should make it obvious which account owns each connection and how failures will be detected.

What about AI failures?

AI may technically succeed while producing an answer that is poor, incomplete or outside the expected format. A good AI workflow validates the result before trusting it.

• restricted output formats;
• required fields;
• validation checks;
• safe defaults;
• human review for important decisions;
• stopping when the result is incomplete.

The goal is not to make AI infallible. It is to contain uncertainty.

How should alerts work?

A useful alert should say what failed, which customer/job/order is affected, whether action is required now, what has already been protected and where somebody should look next.

“Order 2147 could not move to production because delivery date is missing. Customer follow-up has been created. No production record was generated.” is more useful than “Workflow error: step 6 failed.”

Who should receive alerts?

Only people who can act on them. Technical failures may go to whoever maintains the system; missing customer information belongs with the account owner; operational exceptions belong with the relevant manager.

What is a retry?

Some failures are temporary. Retrying a safe read operation may be sensible; blindly retrying a charge or contract-send action can create duplicates or worse. The workflow should know which actions are safe to repeat.

What is a manual fallback?

Every important automated process should have a way to continue manually if required: failed booking integration → staff call the customer; AI cannot classify → human-review queue; document generation fails → task created with source information attached.

How often should automations be checked?

Monitoring frequency should reflect business risk: how often the workflow runs, how quickly failure would hurt, whether customers or money are affected and whether staff would notice another way.

What should maintenance include?

• reviewing error logs;
• checking important integrations;
• reconnecting expired permissions;
• testing after platform changes;
• updating workflows as the business changes;
• reviewing stuck records;
• documenting changes;
• periodically testing failure routes.

Why documentation matters

If only the person who built the automation understands it, the business has created a new dependency. Useful documentation identifies what the workflow does, what triggers it, which systems and accounts it uses, important rules, failure behaviour and where logs or affected records can be found.

What Lawton Workflows can provide

Monitoring and maintenance can be designed into a build from the start: validation rules, error logging, exception queues, staff alerts, late/stuck-record detection, permission checks, safe retries, human fallback routes, periodic maintenance and repair of unreliable existing automations.

The goal is not “zero errors forever”. It is for errors to be visible, contained and recoverable.