An automation can outlive its original purpose
The team replaced its CRM, but the old transfer still runs. Nobody has read another report for months. Successful logs establish that something executes, not that it remains useful.
A regular review connects each automation to its purpose, owner, and dependencies. Establish what the team still uses before deciding to repair, simplify, or retire it.
Use the review register and retirement plan and fictional example. Add them to your existing process documentation if that works for the team.
Ask about the current benefit
Record the trigger, inputs, outputs, latest execution, and person using the result. Distinguish the owner from the original author. An author who left the business does not remove the need for someone to handle changes and exceptions.
Check whether the output supports a current action. A report with no reader may be a retirement candidate. A quarterly report is not necessarily redundant because nobody opened it this week.
Choose to retain it with a confirmed owner, change it for the new process, observe it until a specified date, or prepare retirement. Record the reason alongside the status.
Review dependencies in both directions
Establish what triggers the workflow and what consumes its output. Dependencies may include another scenario, manual work, an external webhook, or a client notification. Inspect waiting, running, and repeating work separately. The latest successful execution does not list all of it.
Changing the schedule does not necessarily stop every entry route. Make describes On demand as execution initiated manually or through an API call. Removing the recurring schedule therefore does not establish that a scenario cannot run.
Check the stopping mechanism and waiting executions in the actual tool. Instructions and behavior differ. Do not rely on a generic inactive label without inspecting the input route.
Prepare a replacement and a recovery route
Before stopping a transfer, assign someone to receive new cases manually or through the replacement route. Preserve configuration and necessary evidence under your agreed retention process. Do not copy passwords into the register.
Record the stopping time, observation period, and conditions for recovery. Recovery is more than switching the workflow back on: new events may have arrived during the pause. Check which were handled manually before processing them again.
The fictional example retires an old weekly summary after confirming the new report and its recipient. It observes one complete weekly cycle for missing work. Choose the period for other workflows according to their frequency and consequences.
Separate stopping, deletion, and spending
Stop the workflow and check its replacement first. Deleting configuration has a different effect and may complicate recovery. Do not remove shared-account permissions used by other automations.
Review subscriptions and supporting services as well. Stopping a scenario does not automatically cancel its paid plan. Decide separately what is unnecessary, who will change it, and under which terms.
Begin with one workflow and an explicit outcome check. Update the register after a significant process change and at an agreed interval. The resulting inventory also improves your workflow cost review.
Documentation checked October 10, 2026. This is a prepared procedure, not an action already taken against your services.
A concrete first retirement: a scheduled Make scenario
Use this variant only for one scheduled scenario with verified entry routes. On the scenario details page confirm its name and ID, then set ON/OFF to inactive using the Make instructions. Reload the details and record the state and time. An inactive scenario can still be started manually with Run once; tell the team it is retired. This change is not a complete execution ban.
Before the change, list running and waiting executions, webhooks, API and manual entry routes. An unknown route or unresolved execution blocks retirement until the owner verifies safe completion or its specific stopping mechanism. This step controls scheduling; it does not promise to cancel every running or queued effect.
Watch the next expected execution time and replacement output. If the old scenario still runs, retirement is incomplete: identify the entry route and do not blindly repeat writes. Retain the configuration. For an incident use automation repair and recovery; canceling a paid service is a separate decision.