At a glance
What you need to know.
An employee management system connects people records with policies, approvals and business systems. This reference design makes identity, effective dates and access boundaries explicit. It separates approved changes from payroll notifications or account provisioning, so integration failures can be recovered without losing the initiating decision.
How the system fits together.
A reference flow to adapt to your data, users and operating constraints.
- 01
Establish employee identity
Create a stable employee record and map external payroll or identity-provider identifiers.
- 02
Capture a request
Collect the relevant fields, supporting evidence and effective dates for the workflow.
- 03
Apply policy
Check eligibility, balance rules and the requester’s scope using a versioned policy.
- 04
Obtain approval
Route to the authorized manager or HR reviewer and retain the decision history.
- 05
Publish the change
Commit the accepted change and deliver recoverable integration jobs to downstream systems.
- 06
Reconcile and audit
Compare acknowledgments, investigate exceptions and preserve a traceable employee history.
Separate identity from employment history
Model the person, employment relationship, position and organizational assignment separately. A rehire should not erase the previous employment period, and a department transfer should retain its effective date. Define which system owns each field: payroll may own pay calculation, HR may own employment status, and the identity provider may own login credentials. Synchronization needs stable identifiers and explicit conflict handling.
In an illustrative leave workflow, the employee requests dates, a policy evaluates the applicable balance, and an authorized manager approves or rejects the request. Approved leave updates the ledger and creates a payroll integration job. A later cancellation is a new recorded transition with its own authorization. Editing the original approval in place would obscure why payroll received a different instruction.
Design access around records and responsibilities
An employee can view appropriate personal records, a manager can access a defined reporting scope, and HR specialists receive permissions for their assigned duties. Sensitive compensation, identity documents and health-related information may require narrower controls than general profile data. Enforce these decisions on the server for reads, edits, exports and attachments. Hiding a salary field in the interface is not an access policy.
Changes to reporting relationships and employment status must update access predictably. Test a transferred manager, a delegated approver, a terminated account and a guessed employee identifier. Store attachments privately and authorize their download. Keep audit events for relevant changes, including actor, action, record and outcome, without duplicating entire confidential documents into logs. Agree retention and deletion rules with the responsible business and legal owners.
Keep approval state independent of notifications
Use an explicit workflow state machine for drafts, submitted requests, approvals, rejections and cancellations. The allowed transitions should depend on the current state and caller authority. Concurrent requests need a strategy for balance reservations or transactional validation, especially when multiple leave requests compete for the same entitlement. Preserve the policy version used in a decision so reviewers can understand historical results.
Send payroll and provisioning changes through a recoverable job mechanism. At-least-once queue delivery can repeat a message, so a stable change identifier and idempotent consumer are essential. An email failure should not reverse a completed approval. An integration timeout may have occurred after the remote system accepted the update; reconcile its receipt before retrying a consequential change. Surface unresolved exceptions to an owner.
Validate lifecycle events before rollout
Test joiners, transfers, extended leave, leavers and rehires with representative policies. Include effective-date boundaries, partial-day requests, delegated approvals and corrections after a payroll cutoff. Acceptance should cover accurate balances, allowed transitions, unauthorized access rejection and reconciliation against the downstream system. Measure the time requests spend awaiting a decision separately from integration processing time.
A single modular application can be easier to maintain while workflow volume and team ownership are modest. Separate services become useful when payroll connectors, document processing or identity provisioning need independent controls or scaling. That separation adds event delivery and reconciliation work. Start with the simplest architecture that supports the actual policies, provide a manual exception process and demonstrate recovery from a failed downstream update before launch.
Before you start.
- Assign ownership for employee fields and external identifiers.
- Define effective dates and permitted workflow transitions.
- Verify record, export and attachment permissions.
- Test duplicate delivery and payroll reconciliation.
Common questions.
Should payroll and HR share one database?
They can in a small, deliberately integrated system, but field ownership and permissions still need clear boundaries. Separate products usually integrate through defined APIs or controlled exchanges rather than unrestricted database writes.
What happens when payroll is unavailable?
Keep the approved HR change and its pending integration state. Retry within the agreed policy, reconcile remote outcomes and expose unresolved failures for operational review.