The tool under your automation is about to change: five questions to ask first

Your invoicing automation ran every Monday for eight months. Last Monday it did not. Nobody on your team touched it.

The automation did not fail. The ground under it moved. That is the most common way a working automation dies, and most owners find out from a customer rather than from a system.

Working automation rarely breaks on its own. The ground moves under it¶

Every automation you own runs on a platform somebody else controls. That platform ships security fixes every few weeks. Every year or two it ships a major version that rewrites the pieces your workflows sit on.

Your workflow did not change. Its foundation did.

This is not a bug, and it is not bad design. It is the normal cost of building on someone else's tool. The automation you paid for in the spring can stop working in December with nobody at fault.

The invoicing workflow nobody knew was out of support¶

An 18-person services firm had an automation that pulled approved timesheets into invoices every Monday morning. A contractor built it two years earlier and had since moved on.

The platform underneath ran a routine update. The automation stopped writing invoices and reported nothing. The firm found out on Thursday, when a client asked why they had not been billed.

The version it was built on had left support almost a year before. Nobody had been told, because nobody was on the list to tell.

Two kinds of change: apply the patch, plan the major version¶

A security patch is small and frequent. It closes a known hole. Apply it promptly. The risk of applying it is low when someone owns the job. The real risk is skipping it for a year.

A major version is different. It changes how the platform works, which means it can change how your workflows behave. Plan it, test it, schedule it. Never run one against live work on a Friday afternoon.

The test is simple. If the change closes a hole, move fast. If the change alters how things work, move carefully.

Five questions to ask whoever built or maintains your automation¶

Ask these in plain language. You do not need to understand the technology to judge the answers.

1. Which version are we on, and is it still supported?
2. Who is told when a security release comes out, and what happens next?
3. Where do we test a change before it touches real work?
4. If the upgrade breaks something, how do we go back?
5. Which of our workflows touch the parts that are changing?

What a good answer sounds like, and what a shrug sounds like¶

A good answer is specific. It names a person, a place, and a timeframe. "We are on the current supported version. Patches come to me by email and I apply them within a week. We test against sample data in a copy of the workflow. We keep the previous setup so we can switch back in under an hour."

A shrug sounds like "it should be fine" or "we will look at it if something breaks."

If you get the shrug, do not escalate. Ask for the same five answers in writing, with a name against each one, by a date you set. If the answers never arrive, that is your answer. You do not have an upgrade owner. You have an assumption.

One line per workflow, on the scorecard you already run¶

This does not need a new system. It needs four columns: platform, version, upgrade owner, next planned upgrade.

If you already run A Weekly AI Scorecard Any Owner Can Run in 15 Minutes, add one line per automation and review it monthly. It takes minutes once the rows exist.

Any row you cannot fill in is the work. A blank upgrade owner is the one that will cost you.

Keep exploring¶

If you want a clear picture of what is running, what it sits on, and who owns the next upgrade, start the AI Readiness Audit or contact FIT.