Skip to main content

Offer Storage

Audience​

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

Reference Content​

Summary​

The Offer aggregate persists lifecycle status, joining and validity information, an owned compensation value, public-action state and three dependent collections.

Relationships​

Letters, revisions and approvals are configured dependent entities with cascade deletion from Offer. Candidate and opening references are logical identifiers rather than configured cross-aggregate relationships.

Mapping and constraints​

  • Offer status is stored through an enum-to-string conversion.
  • Compensation is an owned value object within the aggregate.
  • The compatibility identifier is unique.
  • The public-action token is unique; its value must be treated as secret and is not documented.
  • Tenant/candidate and tenant/opening access paths are indexed.
  • Dependent collections have offer-oriented support indexes.

Lifecycle use​

Acceptance can create or resume onboarding; rejection updates offer state. Revision and approval history remain Offer-owned evidence. A successful onboarding completion does not collapse or delete the offer record.

Privacy​

Compensation, signatures, rejection detail, tokens and personal candidate information are sensitive. This page documents shape and ownership only.

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/Domain/Recruitment/Offer.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