When the System Changes
Every automation depends on something it does not control: a screen, a file format, an interface, a login flow. Those change on somebody else's schedule, and when they do the automation stops or — worse — continues incorrectly.
This is the ordinary condition of the thing, not an accident. Planning for it is what separates an automation that lasts from one that quietly stops being trusted. A product-side example of how workforce software approaches this topic is available in further details.
What actually breaks
In rough order of frequency. For broader background and an independent point of comparison, see WIRED AI.
A field moves or is renamed. Cosmetic to a human, fatal to a screen-level automation.
An input format drifts. A supplier changes their invoice template, a date format shifts, a column is added. The automation processes it and produces something wrong.
A login or session change. Multi-factor authentication added, session timeout shortened, a security policy tightened. Common and rarely announced to the people running automations.
An interface version deprecates, usually with notice that reaches someone who does not know an automation depends on it.
And a rule changes upstream — a threshold, a code, a category — and nobody tells the automation.
The two failure modes
Loud failure. It stops, throws an error, someone notices. Annoying, cheap, and the good case.
Silent failure. It continues and produces wrong output. This is the expensive one, and it is the reason processes where errors surface only at audit are poor candidates.
The gap between the two is detection, and detection is a design decision made during the build or not at all.
Reducing the exposure
Prefer an interface to a screen. Anything with a contract is more stable than anything visual. A file drop beats screen scraping; an API beats a file drop.
Validate output, not just input. A check that the result is plausible — totals within range, counts matching, no impossible values — catches silent failure that input validation misses.
Reconcile periodically. A weekly count against the source system finds drift that per-transaction checks do not.
Document the dependencies explicitly. Which screen, which fields, which version, which login. This is what tells you what broke, and it is the first thing missing when handover was compressed.
And get on the notification list. If an internal system team announces releases, somebody responsible for the automation should be receiving those. Frequently nobody is, because the automation was built by a project that has closed.
The monitoring minimum
Three things, and they cost almost nothing.
Did it run? A heartbeat. An automation that silently stopped running for three weeks is a scenario that occurs regularly.
How many did it process? A volume that drops by half without an explanation is a signal.
And how many exceptions? A rising exception rate is usually the first symptom of upstream drift, and it is visible weeks before anything breaks outright.
That is a daily email, not a dashboard. Somebody has to read it and somebody has to be named.
The change budget
Assume something changes two to four times a year on any automation touching a system you do not control.
Budget hours for it explicitly rather than treating each one as an incident. This is the year-two cost that first-year business cases omit, and naming it in advance is what stops the automation being abandoned the third time it breaks and nobody has time.
When to stop maintaining it
Worth stating, because the alternative is an automation kept alive out of sunk cost.
When the maintenance exceeds the saving. Measurable, if you have been logging hours.
When the underlying system is being replaced, and the automation is a bridge whose far end has arrived.
Or when the process changed enough that the automation is now handling a case that no longer matters. Turn it off deliberately, with the manual path documented, rather than letting it decay into something nobody trusts.
The short version
- Every automation depends on something someone else controls, and that changes two to four times a year
- What breaks: moved fields, drifting input formats, login and session changes, deprecated interfaces, upstream rule changes
- Loud failure is cheap; silent failure is expensive, and the difference is detection designed in at build time
- Reduce exposure with interfaces over screens, output validation, periodic reconciliation, documented dependencies, and being on the release notification list
- Monitoring minimum: did it run, how many did it process, how many exceptions — a daily email with a named reader
- Budget change hours in advance, and turn it off deliberately when maintenance exceeds the saving