Saga compensation design
Compensation requires its own permission checks
A corrective action can release resources, reverse a commitment or notify a customer. Give it explicit authority rather than treating recovery as an unrestricted system privilege.
In this article
Define the corrective capability
List what each compensation may change and which original effect it is allowed to address. Releasing reservation R91 is narrower than granting the coordinator general stock-adjustment access.
Tie the correction to the saga and original operation. This helps prevent a replay or malformed request from targeting an unrelated record.
Use trusted state to resolve ownership and eligibility. A payload claiming that an operation belongs to a particular account should not establish its own authority.
Separate service identity from business permission
A background coordinator may use a service account with technical access to several systems. Document the application checks that constrain it to the approved workflow.
Decide how authority behaves when the original user loses access or leaves the organisation. Some recovery work may be an organisation-owned obligation that continues under a designated role. That should be explicit, not an accidental consequence of a long-lived credential.
Manual recovery needs its own role and audit trail. Operators who can replay or compensate workflows can cause consequential effects even if they cannot use the ordinary business interface.
Limit data in recovery records
Store the identifiers and facts needed to resolve the effect, avoiding broad snapshots of unrelated customer data. Compensation logs and incident exports can create additional copies with different audiences.
Protect source payloads and correction reasons according to their content. A status dashboard can often show saga identity, state and age without exposing the complete request.
Review downstream destinations for notifications or corrective documents. Recovery should not send information to an address supplied by untrusted content without the normal destination checks.
Test authority changes and wrong targets
Attempt compensation against another account's reservation, an effect not belonging to the saga and an operation already resolved. Verify the documented rejection or idempotent outcome.
Pause a workflow, change relevant permissions and resume it under the intended policy. Inspect both automated and manual paths.
The review should establish who may perform each correction and why it remains appropriate for the current effect. Recovery is part of the business authority model, not a reason to bypass it.
Primary sources
OWASP: authorisation guidanceMicrosoft Learn: compensating transactionsReferences checked 11 September 2026.