You will be able to run a quarterly review that decides which automations to keep, change or switch off.
Open your automation tool and look at the list of flows that are switched on right now. If you have used an automation tool for a year or two, you probably have a pile of old flows you no longer need. Say there is one for a promotion that ended last June, two test flows from your first week, and one that copies orders to a sheet nobody opens because the person who asked for it changed jobs (these are example cases). Some of them are probably still switched on, still running and still connected to your work accounts.
Automations do not retire themselves. If you don't review them regularly, flows pile up and cost money, and they keep access to your accounts open long after anyone needs it. A quarterly review prevents this. Once a quarter, you check every flow you own and decide whether to keep it, change it or switch it off. Then you remove any access you no longer need.
Start by listing every automation you own. Keep two things open beside you: your log from lesson 7.3, and your cost sheet from lesson 8.1, What an automation really costs. Most of the numbers you need come from these two. Run each flow through four checks:
Run count: how many times the flow ran this quarter, compared with the previous quarter. A sharp drop may mean the trigger has stopped firing, or the work the flow supports has dried up. A sharp rise may mean volume is growing, and that affects cost. Failure rate: of those runs, how many failed or went to review. You work it out by dividing failures by total runs. Time saved: the hours the flow saved this quarter, using the per-run saving from your cost sheet. Also check whether anyone still uses the result, because a flow that writes to a sheet nobody reads saves no time. Cost: this quarter's cost in plan share, usage, AI charges and your own maintenance time. Compare it with the time saved and the error cost the flow prevents, using the method from lesson 8.1.
Failure rate is the number of failed runs, or runs sent to review, divided by the total runs in the period. Take a flow that ran 195 times in a quarter with 6 failures, both example figures. Its failure rate is about 3 percent. The trend matters more than the single number. If the rate creeps up quarter by quarter, something has usually drifted. The input may have changed shape, or a prompt written for last year's messages may no longer fit this year's.
Write the four results in one row per flow. For a handful of flows, the whole exercise should take under an hour.
Make the easy decisions first, and don't leave a flow on just in case. If a flow has not run for a quarter, or it runs but produces something nobody uses, switch it off.
Unused flows cause problems in three ways. First, every live flow holds connections to your accounts, as lesson 3.3, What a tool can see once you connect your accounts, explains, so an unused flow is an open door that nobody is watching. Second, it may be using part of your plan's allowance. Third, when it breaks it sends alerts about something nobody cares about, and that teaches people to ignore alerts.
Switching off does not have to mean deleting. Turn the flow off and note in your review that it is off and why. If nobody has asked for it back by the next review, delete it then.
Some flows are used and still work, but have become hard to manage. The signs build up gradually. Each new requirement added another branch, and each odd case got its own filter. Formatter steps now fix the output of other formatter steps. Any change means an hour of tracing paths, and the runbook you wrote in lesson 8.2, Document it so someone else can fix it, keeps growing.
When you see these signs, you have three options. The first is to rebuild the flow more simply, now that you understand the real requirements. The second applies if the process underneath has changed: go back to lesson 1.2, Fix the process before you automate it, and fix the process before you touch the flow. The third applies when the logic is complex enough that a no-code tool is the wrong place for it, since a short piece of code can replace a canvas of fifty steps. Writing code is outside this course. It is covered in the course Build with AI: APIs, agents and small apps, which teaches you to write small programs with AI help and call model APIs directly, and it is the sensible next step if your flows keep needing workarounds.
A connection is the permission an automation tool holds to act as you in another app. Switching off a flow does not remove its connections. They stay in the automation tool, still allowed to act as you, until you remove them.
The last step of each review has two parts. First, open the automation tool's list of connections and delete any that no current flow uses. Then go to each connected app's security or account settings, find the list of third-party apps that have access, and revoke any you no longer use. Check both places, because removing a connection inside the automation tool may not revoke the permission inside the app.
Arif uses his firm's email account in his flows. In his first review, he found three connections to the firm's email from flows he had switched off months earlier, and he revoked all three. One of them came from a tool he had stopped using entirely.
You have built at least three flows during this course: the two test flows from lesson 3.4, Build the same small flow in two tools, and your main flow, perhaps with an invoice flow beside it. That is enough for a first review. Block out an hour, open your automation tool's list of flows, and keep your log and cost sheet beside you for the activity below.
Create a review template with the four checks and run it on every automation you have built so far.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).