Skip to content
SteveTechArcSteveTechArc Courses

There's No Rollback Across Systems

Module 3 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: The User Waits · Next: Orchestration or Choreography

The question this module answers: When a piece of work spans several systems and one step fails, what can be undone automatically, and what do you have to design?

Inside Salesforce, Undo Is Built In

Section titled “Inside Salesforce, Undo Is Built In”

Start with what you can count on. Inside Salesforce, a transaction is a real promise. If an Apex transaction fails, “all database changes are rolled back.” If you need finer control, savepoints let you go back to a point partway through. And for a call where a person waits, Salesforce’s patterns guide relies on the same promise: “Changes aren’t committed to Salesforce until the caller receives a successful response.” The Data Architect course walks through all of it: all, part, or back to here (Safe to Retry).

That’s one database, with one system in charge of it. Everything in the transaction succeeds together, or none of it happened.

Across Systems, There’s No Shared Undo

Section titled “Across Systems, There’s No Shared Undo”

Now go back to module 1’s order. Accounting confirms the balance. The ERP accepts the order and saves it. Then the inventory update fails.

What rolls back? Nothing, by itself. The ERP’s order is saved in the ERP’s own database, committed by the ERP. Salesforce can’t reach into the ERP and undo it, and the middleware can’t either. Each system committed its own step, on its own, the moment it finished.

Microsoft’s architecture guide says it in one line: “Traditional database guarantees like ACID aren’t directly applicable to multiple independently managed data stores.” ACID is the name for that all-or-nothing promise. It holds inside one database. It doesn’t stretch across several.

There is an old technique for making several systems commit together, called two-phase commit, where a coordinator asks every system “are you ready?” and then tells them all to commit at once. In practice, integrations almost never use it. The systems often don’t support it, and the pattern catalogs say why even when they do: “it’s often undesirable to couple the service to both the database and the message broker.” Salesforce and the ERP aren’t going to hold each other’s transactions open while they wait for each other.

One undo inside, none across One undo inside, none across: two panels. Inside Salesforce: one database, one transaction; everything commits together, or nothing does; a failure rolls back every change; a savepoint goes back partway. Across systems: each system commits its own step, the moment it finishes; a failure later doesn't undo an earlier step; nobody can roll back another system's database; an undo is a new step, designed and sent. Underneath: inside one system, undo is built in; across systems, undo is something you design. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-INT-OR-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} Inside Salesforce one database, one transaction Everything commits together, or nothing does. A failure rolls back every change. A savepoint goes back partway. Across systems each system commits on its own Each step commits the moment it finishes. A later failure doesn't undo an earlier step. Nobody rolls back another system's database. An undo is a new step: designed and sent. Inside one system, undo is built in. Across systems, undo is something you design. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Inside one system, undo is built in. Across systems, you design it.

So across systems, “undo” isn’t a rollback. It’s a new step: a cancel sent to the ERP, a refund sent to accounting. It’s designed, sent and logged like any other call, and it can fail like any other call. That’s module 5.

The State in Between

Section titled “The State in Between”

Here’s what follows, and it’s the part that catches people. While the steps are running, the work is neither done nor not done. The order is in the ERP, but inventory hasn’t been updated. The balance was checked, but the order hasn’t arrived. The work is in between.

And other people can see it while it’s in between. Microsoft’s guide again: “there’s no built-in isolation across services.” Someone runs a sales report and counts an order that’s about to be cancelled. A warehouse picks stock for an order whose payment hasn’t cleared. The guide calls it a dirty read: reading data “that another saga has modified, but the modification isn’t complete.”

You can’t make the in-between state go away. You can make it visible. The usual way is a status on the record that says plainly, this isn’t finished. Microsoft’s guide calls that a semantic lock: an application-level marker “to indicate that an update is in progress.” In Salesforce terms, it’s a field. The order says Pending until every step has finished, and everyone, people and automation, knows what Pending means.

The Order’s States

Section titled “The Order’s States”

So the status deserves the same care as any other piece of the data model. For module 1’s order, as a labelled example:

The order's states The order's states. Draft: the user is still building it. Pending: submitted, steps still running; the balance check and the ERP order in progress. From Pending, three ways out: Submitted, every step done, the ERP's order number stored; Rejected, over the customer's limit, nothing sent to the ERP; or, if it stays Pending too long, Needs attention, with an alert to the owner. From Needs attention, if it can't finish: Undone, the steps already taken cancelled one by one. Underneath: every state has a meaning, a rule for what may happen to it, and a way out. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-INT-OR-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} Draft the user is still building it Pending submitted; steps still running; can't ship, not counted Submitted every step done; the ERP's order number stored Rejected over the limit; nothing sent to the ERP Needs attention Pending too long: the owner is alerted Undone the steps already taken, cancelled one by one submit all steps done over the limit too long can't finish Every state has a meaning, a rule for what may happen to it, and a way out. HOW TO READ IT in between: a lock others respect finished stopped, or stuck © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Every state has a meaning, a rule and a way out.

For each state, the design says three things:

  • What it means. Pending means the steps are running and nothing downstream should treat the order as real. Submitted means every step finished.
  • What may happen to it. A pending order can’t be shipped, isn’t counted as revenue, and can’t be edited, because the systems behind it are working on the version they were sent. Those rules live in validation rules, in report filters, in the warehouse’s own logic. That’s how the status acts as a lock.
  • How it gets out. Every in-between state needs a way out, and a time limit. An order that has been Pending for four hours isn’t pending. It’s stuck.

Eventually, With an Owner

Section titled “Eventually, With an Owner”

Across systems, you trade “consistent right away” for “consistent eventually”. That’s a fair trade, and it’s how most integrations work. But “eventually” needs two things, or it becomes “never”.

A limit. How long may the work stay in between before someone looks? Minutes for an order a customer is waiting on. A day for a nightly reconciliation. Write the number down, and alert when it’s passed (chapter 14 module 6). The oldest open item is one of the numbers on the morning report (chapter 14 module 8).

An owner. Someone whose job it is to get stuck work to a final state: finished, or undone. Not “the integration”. A person or a team, named in the runbook.

The Data Architect course designs fields and the rules that guard them (Keeping Data Consistent). An in-between status is exactly that kind of field. It needs controlled values, rules about who may change it, its history kept, and a report on anything that’s been in between too long. It’s data, with an owner.

Test knowledge. Know that a Salesforce transaction rolls back as a whole (with savepoints for part of it), but there’s no rollback across separate systems: each commits its own work, so failures partway through need compensating steps and a status that shows the work isn’t finished. Know the trade: eventual consistency, with a limit and an owner.

Beyond the exam: what AI changes. Agents make the in-between state more common, not less. An agent that books, charges and notifies across three systems has the same problem as the middleware, and an agent that reads a pending order as finished makes a dirty read at machine speed. Give every in-between state a clear name and a rule, and an agent can respect it like anyone else.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • Which work spans systems, and so can’t rely on a rollback.
  • The in-between states, their names and what each one means.
  • What may happen to a record in each state, enforced where people and automation will hit it.
  • How long each in-between state may last, and what happens when it’s passed.
  • Who owns stuck work, and gets it to a final state.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.