Skip to main content

Database Tenant Isolation

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​

All three runtime contexts apply global query filters to their scheduling/calendar entities. Attendance and Leave compare stored tenant identity with an HTTP-derived tenant context. The monolith similarly filters optional tenant fields.

Write protection​

Canonical commands construct new entities with required tenant identity. The monolith SaveChanges override stamps the current tenant on added or modified tenant-bearing records for non-privileged callers.

Bypasses​

Privileged administrator context bypasses global filters. Development seeders and backfill/validation processes deliberately ignore filters because they run without an ambient request tenant. Design-time null contexts cannot provide ordinary tenant identity.

Risks​

Filters protect reads only when context is correct. Header trust, privileged access authorization, bulk process scoping, and cross-tenant negative testing require confirmation. Assignment-to-shift consistency is not enforced as a tenant-composite relationship.

Source References​

  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Infrastructure/Persistence.cs
  • microservices/src/leave-service/Infrastructure/LeaveDbContext.cs
  • Data/AppDbContext.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