How hire-to-exit HR modules should connect

Hire-to-exit only works when every HR module points at the same employee identity. Recruitment should become an employee record, not a copied row. Attendance, leave, payroll calculation, onboarding, lifecycle events, assets, and SOPs should read and write that record instead of keeping private copies of name, manager, location, and pay structure. The workflow is not a stack of isolated apps. It is a single person moving through stages, with different modules owning different events.

This article maps those handoffs. It does not replace the commercial HRMS overview, and it does not treat onboarding as the whole employment story—that distinction lives in employee lifecycle versus onboarding. Use this page when you are designing how modules connect, including employee management as the master and employee lifecycle for events after the first week.

What “one employee identity” means in practice

Identity is more than a name. It is a stable key—usually an employee code—plus the fields every process must see in the same way: legal name, joining date, department, reporting manager, location, employment type, and the compensation elements payroll calculation needs. If attendance uses a biometric number that is not linked to that key, you will spend month-end matching punches to people. If recruitment uses an email that later differs from the HR master, you will have two humans who are one person, or one person who is two humans.

Write-path discipline matters as much as the key. Only certain roles should change certain fields. Payroll should not invent a joining date because a sheet was late. When modules cannot share the key, teams create “mapping tabs”—identity debt.

Dayzen HRMS is built as hire-to-exit people operations around that idea: published modules for employee management, attendance, leave, payroll calculation and payslips, recruitment, onboarding, employee lifecycle, assets, and SOP. The value is the shared person, not a claim that every adjacent system (bank payment, PF filing, laptop MDM) lives in the same login.

The employment trail, module by module

1. Recruitment: stages, not project boards

Hiring should track a candidate through stages: sourced, screened, interviewed, offered, accepted, declined, on hold. That Kanban is a hiring pipeline. It is not a Project Management System task board, and it is not performance management. Columns are employment decisions, not sprint tickets. Keep job, recruiter, hiring manager, and offer terms attached to the candidate. When the offer is accepted, conversion should create or attach the employee identity—not leave HR to retype the person into a directory.

Common break: the ATS stays the “real” file because offer letters and interview notes live there, while the HRMS master is created days later with a different spelling. Payroll then asks which record is true. Fix the conversion event: accepted offer writes the employee, and the candidate record is marked hired against the same key.

2. Onboarding: activate the same person

Onboarding is the path from accepted offer to someone who can be scheduled, has documents, and appears in time and pay. Checklists should hang off the same identity. Define “active” for attendance, leave policy, and the next eligible pay run. A welcome email without a master record is not operational onboarding.

3. Employee management: the system of record

The master profile is the hub. Org and grade changes should write here (or through lifecycle events), not in a payroll-only screen. If finance keeps a parallel roster, identity is already split. HR, managers, and employees should not share one edit surface.

4. Attendance and leave: facts that change pay

Attendance captures presence, shifts, and exceptions. Leave captures policy, balances, approvals, and types that interact with week-offs. Both must lock to a cutoff so payroll calculation can consume them without a third interpretation. If leave lives in email and attendance lives in a device export, the employee identity is decorative.

Design the exception path: who can mark on-duty, who can regularise a missed punch, what happens to a pending leave at cutoff. Those rules are operational, not cosmetic. They are also where sandwich policies and location calendars either stay consistent or become arguments.

5. Payroll calculation: consume, do not re-create

Payroll should calculate earnings, deductions, and payslips from the identity plus time and leave outcomes, plus standing compensation. It should not be a place where someone quietly fixes a department or a joining date because the master was wrong. Wrong masters get corrected in the master, with history, then recalculated.

Stay honest about scope. Calculation and payslips can be in the HRMS while government filing and bank salary credit stay with a CA, portal, or bank file. Pretending those are the same module produces failed demos and angry month-ends.

6. Lifecycle events after day one

Confirmation, transfer, promotion, location change, and exit are not “more onboarding.” They are events that change the master and trigger other modules: new leave policy, new shift, new cost centre, asset movement, SOP set for a new role. Lifecycle workflows should write the employee record so attendance and payroll do not need a rumour.

Exit is the stress test. Last working day, notice, recovery of assets, access owners outside HR, and full-and-final inputs must hang off the same person. If exit is a WhatsApp group, modules never see the event and keep paying, keep assigning laptops, or keep showing the person in org charts.

7. Assets and SOPs: operational, not decorative

Assets (phones, laptops, id cards) and SOPs (how work is done in this company) attach to the employee and often to the role. Assignment on join and recovery on exit should use the lifecycle dates, not a separate inventory spreadsheet with nicknames. SOP acknowledgement should be attributable to the same identity that signed the appointment letter. These modules fail when they use display names instead of employee codes.

Handoffs you should draw on a whiteboard

From	To	What must travel
Recruitment (accepted)	Employee master	Legal name, offer terms, planned joining date, hiring manager
Master	Onboarding checklist	Employee code, location, role, required documents
Master + policy	Attendance / leave	Shift or holiday calendar, leave plan, manager for approval
Attendance + leave close	Payroll calculation	Payable days, LOP, overtime if used, hold flags
Lifecycle event	Master + downstream	Effective date, new org or pay elements, asset/SOP changes
Exit event	Payroll + assets	LWD, recovery status, FNF inputs, stop-pay flag

If any arrow is “email a spreadsheet,” that is a break. Temporary breaks during implementation are normal. Permanent breaks become the real process.

Implementation considerations

Sequence identity before volume. Load a clean employee master—or a small pilot group—before you turn on biometric devices for everyone. Map device IDs to employee codes explicitly. Set leave policies and calendars before the first approval week. Only then connect payroll calculation, with a parallel run against the old method until numbers match for reasons you can explain.

Do not stand up recruitment Kanban as theatre while offers still close on WhatsApp. Publish cutoff: exception freeze, leave freeze, compute, payslip release. Banks, PF portals, and IT tickets can stay outside; the employee key they receive must still come from the master.

Common mistakes

• Copy-paste conversion. Hired in ATS, retyped in HR, retyped again in payroll. Each paste is a chance to split identity.
• Device-first attendance. Biometrics without a linked employee code create a ghost workforce that payroll cannot name.
• Leave policy as folklore. If the module cannot express the rule, operators will override until the module is meaningless.
• Payroll as the master. When only finance can “fix” department or joining date, HR reports lie.
• Exit without a stop flag. Access and assets linger; pay continues; the directory still shows a team member.
• Confusing hiring Kanban with delivery boards. Candidates are not tasks. Do not staff recruitment like a project tool and call it done.

A thin example of a connected month

A candidate accepts on the 20th. Conversion creates employee E-1842 with a joining date of the 1st. Onboarding collects bank details against E-1842. On the 1st, attendance starts. A leave request on the 12th is approved by the manager stored on E-1842. Cutoff freezes exceptions. Payroll calculation reads E-1842’s structure plus payable days and produces a payslip. Mid-month a transfer event changes department with an effective date. Next month’s reports and leave approver follow the event, not a hallway conversation. That is hire-to-exit as plumbing, not as a slogan.

Scale the same story to a missed punch or an exit on the 18th. If every tool still uses E-1842, modules are connected. If someone opens a side sheet “because the system is wrong,” identity has drifted. Diagnose by searching five recent people (joiner, leave, exception, transfer, exit) across tools; if you need a legend of codes, you do not have one identity. Publish field winners: master for org, time for punches, leave for balances, payroll for that month’s rupees—not for joining date.

Conclusion

Hire-to-exit is a chain of events on one employee identity. Recruitment stages feed the master; onboarding activates it; attendance and leave produce facts; payroll calculation consumes them; lifecycle, assets, and SOPs keep the same person true until exit. Draw the handoffs, sequence identity first, and keep hiring Kanban in its lane. When you evaluate a connected suite, walk one person through that chain on the Dayzen HRMS module map—and reject any demo that rebuilds the person at every step.