There is no undo button: what happens when your automation dies halfway through

The word "rollback" has quietly broken more automations than any bug

Every few months someone shows me an automation that charges a card, creates an order, updates stock, and sends a confirmation, and then asks the same hopeful question: "If a step fails, it just rolls everything back, right?" No. It doesn't. And the belief that it does is more dangerous than any single broken step, because it lets people ship multi-step workflows with no plan for the moment one of those steps dies halfway through.

That moment is not rare. It is the normal case over a long enough timeline. Networks blink. APIs return a 500 for no reason you will ever find. A payment processor times out on the response while still taking the money. If your workflow touches more than one external system, partial failure is not an edge case you might hit. It is a thing that will happen, and the only question is whether you decided in advance what happens next.

Where the rollback fantasy comes from

Rollback is a real thing. It lives in databases. A database transaction wraps several writes in a promise: all of them land, or none of them do. Move money between two accounts in one database, and if the second write fails, the first one is undone as if it never happened. That works because one system owns all the data and can reach in and reverse itself.

Your automation platform owns none of the data it touches. Each step is talking to a different company's system: Stripe, your ERP, your warehouse, your email provider. Each of those decides on its own, and each commits the instant it acts. The moment the card is charged, it is charged. There is no wrapper around those four systems, and no shared undo, because no single thing has the authority to reverse all of them at once.

Make, n8n, Zapier, none of them change this. They run steps in order. When one fails, the earlier ones stay exactly as they were. That is not a missing feature you can shop your way out of. It is the shape of the problem. Chasing the platform that does "real rollback" across third-party systems is chasing something that cannot exist.

Partial failure doesn't look like failure

When a multi-step workflow dies in the middle, you rarely get a clean error that stops the world. You get a half-finished state that nobody notices, and half-finished is often worse than nothing happened, precisely because it stays quiet.

A few real ones, lightly anonymized. A signup flow added a contact to the mailing tool, then was supposed to flag them in the CRM as "do not contact." First step ran, second didn't. Someone got marketing email for weeks against their explicit wishes, until they complained. A billing job recorded a payment, then was meant to mark the invoice paid. The record landed, the invoice update failed on a character limit, and the customer got a dunning notice for money they had already sent. A fulfillment flow created a shipping label but never told the warehouse, so a paid order sat unshipped for two weeks.

None of these set off an alarm. Nothing was down. Two systems that were supposed to agree simply disagreed, quietly, and the disagreement had consequences. That is the real risk. A loud crash forces someone to look. A silent half success smiles and says nothing.

The three honest options

If rollback is off the table, you have exactly three ways to handle a partial failure. All three are work. None is magic. But honest beats magic when money and trust are on the line.

Roll forward. Retry the failed step until it works. The ERP was gone for forty seconds? Try again in two minutes, then five, then twenty. For a brief outage this is the best answer, because the thing that was supposed to happen still happens, just later. The catch: the step has to be safe to repeat.

Compensate. If the process genuinely can't finish, actively undo what already happened, not with a rollback but with an opposite action. The card was charged and the order can't be created? Refund it. Not "pretend it never happened," but as a real, visible event: a charge, then a refund. That is what engineers mean by a compensating action.

Reconcile by hand. Sometimes the half state is too delicate to resolve automatically, and the right move is to get a human involved. Not as an admission of defeat, but as a deliberate call: this case is rare and expensive enough that a person should look. The trick is making sure the person finds out it happened at all, which means failed runs need somewhere visible to land instead of vanishing into a log.

In practice you combine all three. A few automatic retries first. If that leads nowhere, either a compensation or a ticket for a human. What you never do is pretend there's a fourth option that makes it all cleanly disappear.

Compensation is not undo

The idea that trips people up: a compensating action does not restore the old state. It adds a new step whose effect cancels the old one.

That sounds like a technicality and it is the whole game. Void an invoice and the invoice doesn't vanish; it still exists, now paired with a credit note, which is exactly what your accountant wants. Send a confirmation email by mistake and you cannot pull it back. What you can do is send a second one: "Please disregard our previous message." The first email lives on in other people's inboxes forever. You can only reframe it, not delete it.

This reshapes how you build. For every step with an outside effect, you should know the answer in advance: what is the opposite action? Charging a card has one, the refund. Reducing stock has one, adding it back. Sending an email has no clean opposite, only a follow-up. And some steps have none at all. If your automation told a customer about a price increase, there is no undo. They know now.

That last category is the interesting one. Steps that cannot be compensated are the dangerous steps. Which leads straight to the single most useful build technique.

Order decides how much it hurts

Once you accept that every step commits on its own and some can't be taken back, the order of your steps stops being cosmetic. It decides how bad a partial failure gets.

The rule is plain: do the cheap, internal, reversible things first, and save the expensive, external, irreversible ones for last. The later a step sits, the more certain you are that everything before it worked before you do something you can't undo.

Take the order flow. The original sequence charged the card first, then created the order, then stock, then shipping, then the email. The most expensive, most irreversible step, the charge, sat at the very front. The worst possible place, because anything failing after it means you've already taken money for nothing.

So we flipped it. First the internal checks and drafts: is the customer valid, is the stock there, can the order be staged in the ERP. All repeatable or discardable with no consequences. Only once all of that holds does the one irreversible step run, the payment. And after it, only things that are harmless to redo, like the confirmation email.

That point where "I can still abort" turns into "it's done now" is what we call the commit point. Every multi-step workflow with outside effects has one. The craft is knowing where it is, pushing it as late as you can, and doing only recoverable things after it. If you can't name your commit point, you don't have error handling. You have luck.

Idempotency: the retry that must not charge twice

Roll forward sounds easy: just try again. The danger is that "try again" is unsafe when the first try partly succeeded.

Picture the charge step running, the money moving, and then the processor's confirmation getting lost on the way back. Your automation thinks the step failed and retries. Now you've charged twice for one order. That is not hypothetical. It happens routinely on flaky connections.

The fix is idempotency, a clumsy word for a simple property: running a step twice has the same effect as running it once. Good payment providers give you an idempotency key for exactly this. You attach a unique identifier to each charge, say the order number. If the same identifier shows up again, the provider recognizes it and returns the result of the first attempt instead of charging again. Two tries, one charge.

Not every system offers keys. Then you build the check yourself: before creating an order, look for one with that number; before sending an email, check a flag for whether it already went out. More work, and it's the difference between a workflow you can safely re-run and one where every restart is a coin flip. Rule of thumb: any step that changes something in an external system should be idempotent, or you should know exactly why it isn't.

Remember how far you got

Retrying raises another question: how does the second run know where the first one stopped? Restart a five step workflow from scratch and the early steps run again, including the ones that already worked. Without idempotency that's a disaster. With it, it's wasteful but survivable.

Cleaner is to remember your progress. In practice: the record being processed carries a status field. After step two it reads "created in ERP," after step four "ready to ship." If the workflow dies and runs again later, it checks the status first and skips what's done. It picks up where it left off. That costs one field and a little discipline, and it separates a process you can re-trigger at will from one where you have to sit and guess what already happened. For long-running flows that wait on an approval or an external reply, that status isn't a nice-to-have. It's the only way to resume cleanly after an interruption.

The uncomfortable part about distributed state

There's a point where even the best build technique runs out. The moment two systems independently hold data that's meant to describe the same thing, they can drift apart. Not because someone erred, but because they're two systems with a fallible network between them, and at any instant one of them can know something the other doesn't yet.

Computer science wrote this down decades ago: once systems talk over a network that can fail, you have to choose what matters more when it does fail. You cannot promise both that an answer always comes and that the answer is the same everywhere. For daily life that just means a little disagreement between systems is not a bug you can code away. It's a condition you manage.

So any serious automation setup needs a regular reconciliation. Once a day, or once an hour, a job compares the two data sets and flags the differences. Payments with no order. Orders with no payment. Contacts deleted in one system, active in the other. Not to cause panic, but to catch the small contradictions while they're still small. The retailer from the opening runs one now. It finds a case or two a week, mostly harmless. But it finds them, instead of a customer finding them.

What this means for your automations

If you run a multi-step flow that writes into other people's systems, it's worth an honest look. Not at "does it run," but at "what happens when step three of five dies." Three questions tell you whether the process holds up.

Do you know your commit point? Can you name the step after which the run can no longer be aborted without consequences, and does it sit as late as possible?

Are the outward facing steps idempotent? Can you re-trigger the whole thing without someone getting charged or notified twice?

Where do failed runs land? Is there a visible place and a person who checks it once a day, or do errors dissolve into a log nobody reads?

Those three decide reliability more than the choice of platform ever will. A well thought out flow on a plain tool beats a careless one on the priciest. You will never get rollback across systems you don't own. But you can build so that a partial failure isn't a drama, just a run that either straightens itself out or lands, visibly, on someone's desk.

If you're not sure how your existing automations handle a mid flow failure, we'll look with you. Our free Automations Check walks your most important flows and marks the spots where a half failure could quietly get expensive today. Usually it comes down to two or three steps whose order or safeguards make all the difference.