How to untangle a live automation without breaking it

The automation nobody wants to open

It started as four modules. Then someone added a router for the second product line, a filter for the refund case, a branch for the customer who insisted on a different invoice format. Now it is forty modules wide, it touches the CRM, the spreadsheet, the invoicing tool and two inboxes, and the person who built it has moved on.

It also works. That is the whole problem. Nobody can afford for it to stop, so nobody edits it, so every new requirement becomes another branch bolted onto the side, which makes it harder to edit next month.

The way out is not a rewrite, and it is not a brave afternoon of editing in production. It is a sequence of small reversible steps, each one safe on its own. The tools for that already exist in Make. They are scattered across four corners of the interface, and the documentation contradicts itself about one of them, which is a large part of why people do not use them.

Is there any undo at all?

Yes, and if you have read otherwise, you read it in Make's own help centre.

The page on restoring scenarios, updated 16 July 2026, states plainly:

There's no undo button for scenarios in Make.

• Restore and recover scenario, Make Help Center

The very next page in the same navigation, updated 29 May 2026, is called "Undo and redo scenario changes" and opens like this:

Use Undo and Redo in the Scenario toolbar to reverse or reapply changes to scenarios, such as adding, moving, linking, or configuring modules.

• Undo and redo scenario changes, Make Help Center

Ctrl+Z and Ctrl+Y work, ⌘+Z and ⌘+Y on a Mac. Two pages, side by side in the table of contents, disagreeing about whether a feature exists.

What matters more is the boundary of that undo, which the same page spells out:

So the canvas is reversible and the settings dialog is not. Change the error handling behaviour or the incomplete-executions option and Ctrl+Z will not bring the old value back.

What is the actual safety net?

Version history, and it goes back further than most people assume:

Version history lets you access and restore previously saved scenario versions for up to 60 days. It helps you revert unwanted changes, troubleshoot errors, and safely experiment with new configurations.

• Restore and recover scenario, Make Help Center

Two details decide whether it saves you.

First, versions are the ones you saved. Version history is a record of manual saves, so a baseline only exists if you made one before you started editing. Hitting save before you touch anything is the cheapest insurance in this whole article.

Second, restoring is not one click. You pick the version, click Restore version, and then you must save again:

The restored version of the scenario is not automatically saved.

• Restore and recover scenario, Make Help Center

Miss that last step and you are looking at the old version on screen while the new one is still what runs.

Why not just work on a copy?

Because a copy of an automation is not a copy of a document. It is a second machine wired to the same live systems, and the moment you switch it on it starts doing real things to real data.

Make asks you exactly one question about this while cloning, and the wording is easy to click past. The field is "Keep the states of any new modules the same as those being duplicated":

If you select Yes, the trigger will continue from the last processed item in the original scenario. If you select No, the scenario will start from the initial position, as defined in the module settings.

• Clone a scenario, Make Help Center

Make's own example uses a Google Sheets trigger on a scenario that has already run twice: answer Yes and the clone starts from row 3, answer No and it starts from row 1.

Read that as a business outcome rather than a setting. No means the copy reprocesses everything the original already handled: the same invoices sent again, the same rows written again, the same customers emailed again. Yes means the copy and the original are both eating from one queue, and each record goes to whichever gets there first.

A copy is safe only when you cut its hands off first: no webhook of its own (Make does not carry webhooks over to a clone, which helps), triggers pointed at test data, and destructive modules disabled until you have looked at what it would have done.

What do you cut it into?

Subscenarios, which is Make's own answer to the forty-module canvas. A parent scenario calls a child through the Scenarios > Call a scenario module, and the child does one job.

The documentation frames it around exactly our problem:

Simplify complex workflows: Break down large scenarios into smaller, manageable components that are easier to build, maintain, and troubleshoot.

For example, instead of building a single scenario with dozens of routes to handle lead creation, checking companies, contacts, campaigns, and affiliates, you can split each task into its own subscenario.

• Subscenarios, Make Help Center

There are two calling modes, and the choice is not stylistic. Synchronous: the parent waits for the child to return outputs and then carries on, which you want when the next step depends on the result. Asynchronous: the parent fires the call and keeps going, which you want for anything the customer is not waiting on, like writing to a log or updating a warehouse.

One limit worth knowing before you plan the split:

You can only call a scenario created in your team.

• Subscenarios, Make Help Center

Across teams or organizations you are back to Make > Run a scenario or a custom webhook.

Doesn't splitting it cost more operations?

This is the objection that stops most cleanups, and for the Scenarios app the answer is in the documentation:

Reduce credit usage: Scenarios run via the Scenarios app don't consume credits.

For example, if you call a scenario using the Webhooks and Make apps, each operation will consume credits. With the Scenarios app, you can call scenarios, pass the inputs, and return outputs free of charge.

• Subscenarios, Make Help Center

So the old workaround, gluing scenarios together with webhooks, is the expensive one. If someone told you that breaking up a monolith costs more operations, they were describing the webhook approach, and that advice is now out of date.

Where do you find out when it broke?

The History tab, which holds more than run results. It also records what people did to the scenario:

Change log entries record the following user actions: Scenario scheduling changes, Scenario edits, Scenario activation.

• Scenario history, Make Help Center

Two columns on one screen answer the question that usually takes a week of arguing: the runs stopped looking right on the 12th, and the change log says someone edited the scenario on the 12th. You can also open Details for any run to inspect the bundles each module produced, switch between simple and advanced logs, and export the history as CSV.

How far back the run history goes depends on your plan, so check yours before you promise anyone a reconstruction of last quarter.

The order of operations

1. Save a baseline before touching anything. Version history only holds what was saved manually, so this creates the point you can come back to. Sixty days of headroom starts here.
2. Write down what the scenario is supposed to do, in business terms, one line per outcome. Not module by module: outcome by outcome. This is the list you will test against, and half the time writing it reveals two branches nobody can explain any more.
3. Read the change log before the canvas. If the behaviour changed recently, the log tells you when and by whom, and that is usually faster than reading forty modules.
4. Take one leaf first. The best first cut is a branch that ends in an action and nothing depends on it: the notification, the log write, the archive copy. Move it into a subscenario, call it asynchronously, confirm the parent got shorter and the outcome stayed identical.
5. Only then touch anything with a dependency. Synchronous calls, shared state and anything the customer sees come after you have done the exercise once on something harmless.
6. Change one thing per save. A version you cannot describe in a sentence is a version you cannot roll back to with any confidence.
7. Keep the old path until the new one has run for a full cycle. A week of an unused branch sitting disabled on the canvas is cheaper than the day you discover the month-end case ran through the part you deleted.

What breaks people's cleanups

• Editing in production because the change looks small. The settings dialog is outside undo. A "quick" change there has no keyboard shortcut back.
• Cloning and activating to "see what it does". It does everything, to real systems, either twice over or in competition with the original.
• Splitting by module type instead of by outcome. A subscenario called "all the Google Sheets steps" is not a component, it is the same tangle with an extra hop. Split by the job being done.
• Deleting the branch nobody recognises. The branch nobody recognises is the one that runs on the 1st of the month. Disable it and wait a cycle before deleting.
• Fixing the tangle and leaving the monitoring where it was. If the scenario was too big to understand, it was also too big to notice failures in. Ending with a completion marker you can watch is part of the repair, not an extra - particularly since some failures never raise an error at all, which is how a timeout gets filed as a warning and repeats every night.

When this is a job to hand over

A cleanup is a good weekend project when the scenario is yours, you understand every branch, and nothing irreversible happens if a step runs twice.

It stops being that when the automation touches money or customer communication, when nobody currently at the company can say what all the branches do, or when the business cannot pause it even for an hour. That is a repair with a fixed shape: reconstruct the intended behaviour from the runs, split it into pieces that can be verified one at a time, and keep it running throughout. It is scoped work with a known price, and it is the reason Fix M and L exist.

Sources

• Restore and recover scenario - Make Help Center, updated 16 July 2026. Version history, the 60 day window, and the manual save after restoring.
• Undo and redo scenario changes - Make Help Center, updated 29 May 2026. Undo shortcuts and the table of what is and is not covered.
• Clone a scenario - Make Help Center, updated 18 May 2026. The trigger state question and Make's own row 1 / row 3 example.
• Subscenarios - Make Help Center. Parent and child scenarios, synchronous and asynchronous modes, credit behaviour, team limitation.
• Scenario history - Make Help Center. Run entries, the change log, run details and CSV export.