Skip to main content

Employee Profile Storage

Audience​

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

Reference Content​

Summary​

Employee Service owns the extracted employee aggregate. The compatibility application separately stores workforce and user records, so route choice determines which model is populated.

Extracted model​

Employee has an owned Employment value and eight configured child collections. Children cascade with the aggregate.

Confirmed constraints​

  • Employee code is unique within a tenant.
  • Tenant/status and tenant/department access paths are indexed.
  • Status is stored as a string.
  • Tenant filters cover Employee and its tenant-owned model.
  • Department, designation and manager references are logical; the Employee mapping does not configure cross-aggregate EF foreign keys for them.

Compatibility distinction​

Compatibility completion creates or updates its own workforce and user records. No shared physical key, database relationship or persistence reconciler makes those records the extracted Employee aggregate.

Sensitive data​

Profile, bank, document, contact and employment data require least-privilege access. Field-level encryption and data-subject lifecycle behavior are not established by the inspected mappings.

Requires confirmation​

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

Source References​

  • microservices/src/employee-service/Domain/Employees/Employee.cs
  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

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