Skip to main content

Candidate and Joining Storage

Audience​

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

Reference Content​

Summary​

Candidate is the Recruitment aggregate root for identity/contact data and stage history. Joining is represented by coordinated changes to Candidate stage, Onboarding completion and employee linkage.

Transition​

Candidate mapping​

  • Candidate owns a structured name value.
  • Stage and compensation-approval state use string conversions.
  • Candidate has tenant/stage and tenant/email access paths plus a unique compatibility identifier.
  • Stage histories are configured children and cascade with Candidate.
  • Notes, documents and applications exist in the full aggregate, but only stage history is selected here for lifecycle persistence scope.

Joining evidence​

A completed Recruitment save contains the onboarding completion state, candidate Joined stage/history, audit/timeline evidence and publication intent. Employee creation was committed separately in Employee Service before this save.

Failure implication​

If Employee initialization succeeds but the later Recruitment save fails, source shows no automated compensating action or reconciler. Operations therefore need a reconciliation policy before treating completion as globally atomic.

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/Application/Commands/OnboardingCommands.cs
  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

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