Design compensating actions for partially completed operations

A distributed business process cannot usually roll back like one database transaction. When the third operation fails after the first two completed, recovery is a new business process. Compensation must respect dependencies, side effects and the possibility that a reversal is itself unsafe or impossible.

Build the decision artifact

For each forward step, record its durable result, idempotency key, reversibility, compensating command, approval rule and reconciliation owner. Execute compensations in dependency-aware reverse order, not blindly in reverse timestamp order. Make every compensating command repeatable and observable.

The enterprise delivery lab makes this reasoning executable with synthetic data:

from enterprise_cases import compensation_case

result = compensation_case()
assert result["failed"] == "create_order"
assert result["plan"] == ["disable_supplier_record", "release_budget"]
assert result["automatic"] == ["release_budget"]
assert result["approval_required"] == ["disable_supplier_record"]

After budget reservation and supplier creation, order creation fails. The fixture disables the supplier record before releasing budget, and it requires approval for the more sensitive action. It distinguishes compensation from erasure: the audit trail remains.

Test the failure path

Compensation can fail too. A supplier may already have related activity, or a release call may time out after succeeding. Escalate ambiguous outcomes, retry only with stable keys and provide a manual reconciliation view. Never let an LLM invent a compensating command outside a typed catalogue.

Save evidence that another reviewer can inspect:

• forward/compensation matrix
• dependency and approval rules
• partial-failure tests at every boundary
• reconciliation queue and audit trail

This exercise aligns with the enterprise delivery, secure integration, operations and leadership work in the FDE for Professionals course. The course link describes the pathway; this local draft and its synthetic verifier do not claim that a client deployment, security approval or production result occurred.

Practice task

Take a three-step process and interrupt it after each completed step. Define which effects reverse automatically, which need a person and which can only be reconciled.

Continue learning

This article is part of the Enterprise AI delivery and architecture sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Build a durable workflow for a multi-day business process.
• Continue with Choose serverless, workers or containers from workload constraints.

Reference: Azure Architecture Center: Compensating Transaction.