After a customer submits a form, the system creates a task and sends a confirmation email, then fails while updating the payment status. The screen just says “run failed,” and the person on call can’t tell whether the first two actions actually completed. Pressing rerun here may not fix anything; it may create a second task and send a second email.
In June 2026, Cloudflare added “rollbacks” to its Workflows service: developers can define, next to each step, the compensating action to run if the workflow later fails. When a later step fails, the system runs the compensation for completed steps in reverse order of when they started; if a compensation itself fails, it stops and marks the run as errored.
The question this raises isn’t limited to one platform. Whether it’s a scheduled script, no-code automation, or an AI agent operating external tools, when a workflow stops halfway, first find out what has already happened, then decide whether to retry, compensate, or stop and hand it to a person.
Before rerunning, ask what already happened
If a data read timed out and nothing was written, trying again is usually fine. But creating orders or invoices, sending notifications, processing payments or refunds, and updating customer data or permissions all leave real results. If an AI agent has already edited files or sent messages, you can’t treat it as if nothing happened.
And compensation doesn’t mean restoring the original values. A sent email can’t be recalled; someone else may have changed the same record; records created in external services aren’t necessarily suitable to delete. Microsoft’s architecture guidance is clear: compensation handles completed work according to actual business rules and doesn’t necessarily return the system to its original state. For example, if a travel site booked the flights but couldn’t book the hotel, offering the customer a different hotel may be better than canceling every flight, and that decision should be the customer’s, not the system’s.
Write down three things for each step that changes the outside world
Take an existing workflow, mark the steps that change external state, and for each write down:
What record it leaves: the workflow run ID, the ID returned by the external system, the request result, and completion time. Without these, “timed out” and “failed” look the same, and no one can judge the next step.
How to handle a failure: before creating a task, look up whether one already exists under a fixed ID to avoid duplicates; if sending fails, stop further sends and mark it for review; never automatically rerun payment or permission changes; let a person decide after checking the records.
Who decides the next step: for steps involving money, production customer data, permissions, or external messages, name an owner and spell out which records they check and in what state they press continue.
Cloudflare’s official rules also recommend making steps that may be retried “idempotent”: running the same request several times produces only one result. For example, creating a task with the same order number should return the existing task the second time, not create another. But idempotency only prevents duplicates; it can’t fix something done wrong the first time.
Put irreversible steps last
Microsoft’s guidance has another very practical recommendation: clearly mark “points of no return,” such as external sends or legally binding actions, and schedule them only after all critical checks have passed. In the opening example, creating the task and updating payment status first, confirming everything, and sending the confirmation email last leaves much less to clean up on failure.
When an AI agent is in the workflow and it’s unclear whether the previous step succeeded, or the compensation itself would change production data again, block further actions first; see An Always-On AI Assistant Should Learn to Stop Before It Joins Your Main Accounts. For setting human checkpoints on code-change tasks, see Can a Coding Agent Take This Issue? Only If You Can Describe the First Diff.
The compensating step can fail too
Compensation can fail too, so it also needs to be retryable and logged. Microsoft’s guidance notes that sometimes manual intervention is the only way to recover, and then the system should raise an alert with the reason for the failure rather than silently stopping.
Today, pick one workflow that sends email, changes data, or calls external services, and handle only its highest-impact step. Write one directly executable rule, such as: “If sending the email fails after the task is created, do not recreate the task; keep the task ID and send result, move it to review, and let the named owner decide whether to resend.” Until you can say what has already happened, how to compensate, and who approves, high-impact workflows shouldn’t recover on their own.
AI handoff card
We have a multi-step automation (scheduled jobs, no-code tools, or an AI agent), and I want to confirm that if it stops halfway, a rerun won't do things twice or leave irreversible results.
The method comes from this article: https://boosterminiclass.com/en/posts/workflow-rollback-needs-compensating-steps/
Its view: when a workflow stops halfway, first find out what has already happened, then decide whether to retry, compensate, or hand it to a person. Every step that changes external state should leave a traceable ID, have a written failure-handling rule, and have a named person who decides the next step, and irreversible steps should come after all checks have passed.
Review, read-only, only the workflow configuration and run records I've authorized. Don't rerun, modify, or delete anything.
1. List all steps in the workflow and mark which change external state (creating records, sending email, payments, permission changes, an AI agent's outward actions);
2. Check what record or ID each step leaves on completion, marking gaps as "no record";
3. Recommend failure handling for each step: retry, check then compensate, or stop and hand to a person, with reasons;
4. Check whether irreversible steps come after all checks; if not, suggest how to reorder.
Finally, pick the highest-impact step and write one directly executable handling rule.
References
- Cloudflare official blog: How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/ (2026-06-25)
- Cloudflare official documentation: Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/ [accessed: 2026-10-11]
- Microsoft Learn (official): Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction [accessed: 2026-10-11]
