Business process automation and AI
integration in Cambridge

An automation that works for three months builds a quiet kind of trust. People stop checking the spreadsheet it fills or the emails it sends. Then an access token expires on a Friday evening. The flow stops, and nothing on any screen says so. The first person to notice is often a customer asking where an invoice went.

Failure is the normal state of any step that depends on another system. Passwords rotate. A vendor renames a field. A supplier sends a PDF in a new layout. The question worth answering before launch is who learns about each failure, how fast, and what they are expected to do next.

Start by sorting the steps into two groups. Some failures are loud: the whole run stops and an error is raised. Others are silent. The run completes, but a record was skipped, a field arrived empty, or a filter matched nothing because the incoming data changed shape. Silent failures do far more damage, because the automation reports success while doing less than it should.

Loud failures need an owner with a name. A shared channel where alerts land for everyone usually means nobody acts. Pick one person per automation, plus a backup for holidays, and route the alert to them directly. The message should say which run failed, which record it was processing and what the other system returned. A bare line reading flow error forces the owner to go digging before they can even judge how urgent it is.

Silent failures need counts. If the process normally handles forty orders a day and today it handled three, something is wrong even if every step returned green. A simple daily summary helps here: records in, records out, records skipped, with the reason for each skip. Someone who reads that summary for a week learns what normal looks like. After that, an odd number jumps out.

Retries deserve thought as well. A step that fails because a server was briefly unavailable should try again on its own, a few minutes later, and escalate only if it keeps failing. A step that fails because the data is wrong should not retry at all. Retrying a malformed invoice over and over just produces a pile of identical errors and buries the one alert that mattered.

Then there is the question of what happens to the work while the automation is down. Orders keep arriving. Requests pile up. Decide in advance whether items wait in a queue and get processed when the fix lands, or whether someone handles them by hand in the meantime. Write that fallback down in plain language, because the person on call at a bad moment may never have seen the automation from the inside.

Finally, test the alarms. Break a credential on purpose in a staging copy and watch where the message goes. It is common to discover that alerts are still going to the inbox of a contractor who left months ago. A deliberate failure on a quiet afternoon costs very little. An undetected one during a busy week costs a lot.

An automation earns its place when failures become boring. Someone gets a clear message, knows the fix, and the backlog clears itself. That is the standard worth building toward, and it costs far less to set up before launch than after the first bad weekend.

Most automations are built by one person in a burst of focus. The logic lives in their head and in a canvas of connected boxes that made sense on the afternoon it was drawn. A year later that person has moved to another role. A new rule is needed, and nobody dares to touch the flow because nobody knows what it quietly depends on.

The fix is a short written record that sits next to the automation. It does not need to be long. One page per automation is usually enough, provided it answers the questions a stranger would ask first.

The first question is what the automation is for. Describe the business outcome in one or two sentences, the way a manager would say it out loud. New supplier invoices get logged in accounting and sent to the budget holder for sign-off. That sentence tells a reader what must keep working after any change.

Next comes the trigger and the boundary. What starts a run: a new row, a received email, a time of day, a webhook from another system? And where does the automation stop? Many surprises come from assuming a flow handles a case it was never designed to touch, such as credit notes arriving through the same inbox as invoices.

Then list every system the automation connects to, and the account it uses for each. This part is often skipped, and it causes the worst outages. An automation that signs in to the CRM with the personal login of a sales manager will break the day that manager leaves. Service accounts with clear names, owned by the business, avoid that trap. The page should say where credentials are stored, without containing them.

Record the rules in plain words too, especially the ones that look arbitrary. Orders under a certain value skip review. Anything from one particular customer goes to a named person. Each rule came from a decision somebody made, and the reason deserves a line. Without it, the next editor will either remove a rule that still matters or keep one that stopped making sense long ago.

A small change log closes the page. Date, what changed, who changed it and why. Four columns are enough. When a figure looks different next month, this log is the first place to look.

Keep the page where the team already works, linked from the automation itself if the tool offers a description field. A beautiful wiki article nobody can find is no better than nothing. Update it whenever the flow changes, as part of the same task, instead of treating it as a separate chore that slides to next quarter.

Naming helps as much as prose. A flow called Untitled copy 3 tells nobody anything. A name that states the trigger and the result, such as new supplier invoice to approval, makes the list of automations readable at a glance. The same goes for individual steps inside the flow.

This habit also makes the automation cheaper to hand to an outside developer. Instead of paying for days of reverse engineering, the business pays for the change it actually wants. The page takes an hour to write. It returns that hour many times over, usually at the moment when time is shortest.