The saga pattern for cross-system Dynamics 365 transactions

A business operation often spans multiple systems — placing an order updates Dynamics 365 CRM, debits inventory in F&O, charges the payment processor, ships from the WMS. Each system has its own transaction; there's no global transaction that wraps all four. If one fails partway, the others may have already committed. The saga pattern is how to handle this — multi-step business operations that must succeed-as-a-whole-or-rollback-the-side-effects, across systems that don't share a transaction context.

The problem.

Traditional database transactions guarantee ACID — all operations succeed atomically or all fail. Across systems, ACID doesn't work — there's no two-phase commit across Dataverse, F&O, the payment processor, and the WMS. Each commits independently. If step 3 fails after steps 1-2 succeeded, you need to undo steps 1-2 explicitly — a compensating transaction.

The saga pattern formalises this.

The saga.

A saga is a sequence of local transactions:

T1 → T2 → T3 → T4 (success path)

Each Ti is a transaction in one system. If any Ti fails, compensating transactions run in reverse:

C1 ← C2 ← C3   (undoing T1, T2, T3 if T4 fails)

Where Ci is the operation that undoes Ti's effects. The saga either reaches completion (all forward steps succeed) or fully rolls back (all completed forward steps are compensated).

Two implementation styles.

Orchestration. A central saga orchestrator drives the sequence:

Orchestrator → System A: do step 1
System A: done
Orchestrator → System B: do step 2
System B: done
...

If a step fails, the orchestrator initiates compensation:

Step 3 failed
Orchestrator → System B: compensate step 2
Orchestrator → System A: compensate step 1

The orchestrator knows the full state and recovery logic. Typically built with Azure Durable Functions, Workflow Designer, or similar tooling.

Choreography. No central orchestrator. Each system publishes events; subsequent systems react. A failure publishes a "rollback" event that triggers compensation in upstream systems.

Choreography decouples but distributes the saga logic. Harder to reason about; useful for very loosely-coupled systems.

For most Dynamics 365 cross-system business processes, orchestration is the cleaner pattern.

Implementing a saga.

Order placement example.

Steps:

1. T1: Create order in Dynamics 365 Sales (status = Draft).
2. T2: Reserve inventory in F&O.
3. T3: Charge payment via payment processor.
4. T4: Update Dynamics 365 order to Confirmed; release to WMS.

Compensations:

• C1: Cancel order in Dynamics 365 (status = Cancelled).
• C2: Release inventory reservation in F&O.
• C3: Refund payment via payment processor.

Implementation with an orchestrator (Azure Durable Functions):

// Pseudocode for an orchestrator
public async Task PlaceOrderSaga(OrderRequest order)
{
    try
    {
        await CreateOrderInD365(order);
        try
        {
            await ReserveInventoryInFnO(order);
            try
            {
                await ChargePayment(order);
                await ConfirmOrderInD365(order);
                // Success
            }
            catch
            {
                await ReleaseInventoryInFnO(order); // C2
                throw;
            }
        }
        catch
        {
            await CancelOrderInD365(order); // C1
            throw;
        }
    }
    catch
    {
        // Log; alert; possibly retry
        throw;
    }
}

In real implementations, durable orchestrators (Azure Durable Functions, Power Automate workflows with state, custom workflow engines) handle the retry logic, durability across restarts, and timeout handling.

Compensation pattern principles.

• Compensations are semantically reversing, not bit-for-bit undo. Cancelling an order leaves a "Cancelled" record — it's not deleted. The compensation reverses the business effect, not the technical write.
• Compensations should be idempotent. A compensation may also fail and retry; running it twice produces the same final state.
• Some operations are not reversible. Sending an email; debiting a card (sometimes — refunds may have time limits). Build with the trade-off in mind: irreversible operations need extra care upfront.
• Order matters. Compensations typically run in reverse order; compensating T3 first then T2 is the standard.

Timeouts and SLAs.

Long-running sagas need timeout handling:

• Step times out → consider that step failed → trigger compensation.
• Whole saga times out → manual intervention; alert operations.

Visibility.

A user placing an order shouldn't wait for the full saga to complete if it takes seconds-to-minutes. The pattern: acknowledge the order is being processed (return quickly); the saga runs asynchronously; the user is notified on success or failure.

This UX requires:

• Async API design.
• Status records the user can check.
• Notifications on completion.

Power Automate as orchestrator. Simple sagas can be implemented as Power Automate flows. Limitations:

• Long-running flows have time limits.
• Compensation logic must be hand-written.
• State and visibility through flow run history.

For more complex sagas, Azure Durable Functions or custom orchestration is preferable.

When to use the saga pattern.

• Genuine multi-system business operations that must be atomic.
• Operations crossing 3+ systems where partial completion would be invalid.
• Operations with meaningful side effects that need explicit rollback.

When not.

• Operations within a single system — use that system's transaction.
• Truly fire-and-forget events — if partial completion is acceptable, no saga needed.
• Read-only operations — no rollback needed.

Operational reality. Sagas add complexity. Justify the pattern by the business requirement; document the compensation logic clearly; test failure paths deliberately (chaos-engineering style); monitor sagas in production.