Skip to main content

Tenant Isolation

Audience​

Developers, QA and support engineers, data reviewers, implementation partners, solution architects, privacy reviewers and security reviewers.

Reference Content​

Summary​

Most lifecycle business objects use global tenant filters, but operational ledgers and intentional filter bypasses require explicit review.

Isolation model​

Confirmed controls​

  • Recruitment filters 16 of its 18 full-context objects; processed-event and outbox ledgers are operational exceptions.
  • Employee filters employee, organization and evidence models; its outbox is not globally filtered.
  • Attendance, Leave and Asset filter their tenant business/evidence models and leave operational outbox/event ledgers unfiltered.
  • Compatibility applies global filters broadly and stamps tenant-owned writes through its save pipeline.
  • Notification tenant handling is model-specific and must be evaluated with its consumer authorization path.

Confirmed concern​

The Recruitment active-onboarding-by-offer lookup bypasses query filters and lacks an explicit tenant predicate in that repository method. Public docs omit query details, but the boundary is material.

Assurance boundary​

A global filter is defense in depth, not authorization. Background consumers, administrative reads, public-token paths and filter bypasses must establish tenant context explicitly.

Requires confirmation​

Unless explicitly confirmed above, production migration governance, rollback, reconciliation, retention, privacy, performance, concurrency and operational ownership require confirmation.

Source References​

  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/recruitment-service/Infrastructure/Persistence.cs
  • Data/AppDbContext.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Review cycle: Quarterly