Skip to main content

Payroll Run Storage

Summary

Persistence of Payroll run aggregates and their logical record relationships.

Audience

Payroll developers, QA and support engineers, solution and security architects, and implementation partners.

Reference Content

The sections below describe the confirmed logical storage contract and its implementation boundaries.

Purpose

Describe storage for a Payroll run and its calculated employee outcomes.

Ownership

Payroll Service owns PayrollRun, PayrollRunDetail, and SalaryCalculation records.

Lifecycle

A run is created or reused for a tenant and period, populated during calculation, updated with totals, and may move through freeze/unfreeze lifecycle states. Detail and calculation records are written by calculation paths; compatibility paths also upsert run details.

Persisted fields

Runs retain tenant, period identity, month/year, lifecycle status, aggregate outcomes, freeze metadata, and timestamps. Details retain run and employee references, status, attendance/leave units, calculation components, summarized outcomes, and a structured breakdown. Calculations retain run/employee references, status, summarized outcomes, structured calculation data, and creation time.

Relationships

All arrows above are logical references only. No database foreign keys or navigation properties are configured.

Constraints

Run details are unique per tenant, run, and legacy employee reference. Salary calculations do not have a corresponding uniqueness constraint.

Indexes

Runs have a tenant/period/status search index. Details have a unique tenant/run/employee index. Calculations have a non-unique tenant/run/employee index.

Tenant behavior

All three objects have global tenant filters. Implementation queries that bypass filters include explicit tenant conditions.

Audit behavior

Native calculation and lifecycle changes stage audit and timeline evidence with selected run writes. Compatibility behavior is not identical.

Integration usage

Native calculation stages an outbound event in the outbox in the same SaveChanges call as the run results.

Known limitations

No database-enforced period-to-run or run-to-detail relationship exists. Duplicate SalaryCalculation records are not prevented by a unique index.

Requires confirmation

  • Retention and supersession rules for repeated calculations.
  • Whether all compatibility mutations require timeline as well as audit evidence.

Source References

  • microservices/src/payroll-service/Infrastructure/PayrollDbContext.cs
  • microservices/src/payroll-service/Domain/PayrollEntities.cs
  • microservices/src/payroll-service/Infrastructure/Migrations/PayrollDbContextModelSnapshot.cs
  • microservices/src/payroll-service/Application/PayrollCalculationService.cs
  • microservices/src/payroll-service/Application/PayrollCompatService.cs

See Also

Keywords

  • Payroll database
  • Payroll Run Storage
  • Payroll persistence

Revision Information

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