Skip to main content

Transactions and Save Boundaries

Audience​

Developers, database engineers, QA engineers, support engineers, security engineers, solution architects, and implementation partners.

Reference Content​

This page records source-verified Workforce Scheduling persistence behavior and boundaries.

Summary​

No explicit application transaction was found in shift-policy commands or compatibility services. Each EF SaveChanges call has its provider-managed save scope, but a multi-save command is not proven atomic across calls.

Multi-save workflows​

Shift, policy, and assignment creation first persist generated identities and later persist audit/timeline. Default-policy promotion can save incumbent demotion separately. Compatibility create similarly saves before audit. Update/deactivate and compatibility replacement usually use one save for state plus evidence.

Outbox scope​

The context adds mapped attendance integration events before a save, so mapped events share that save transaction. No scheduling event mapping exists.

Failure behavior​

A later save can fail after core state or default demotion has committed. Compensating behavior and retry/idempotency policy were not verified. Backfill writes entity groups and completion audit in separate saves.

Source References​

  • microservices/src/attendance-service/Application/Services/ShiftPolicyCommands.cs
  • microservices/src/attendance-service/Application/Compatibility/ShiftPolicyCompatService.cs
  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Backfill/ShiftPolicyBackfillAudit.cs

See Also​

Keywords​

  • Workforce Scheduling database
  • Shift persistence
  • Attendance policy storage

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Next review: 2026-10-20