Active, inactive, and exited employee records

Active, inactive, and exited are statuses — not folders

Active means the person is currently employed and should appear in operational queues. Inactive is a reversible pause — long leave or a similar operating hold — if you choose to use that flag at all. Exited means employment ended: keep the record for history, payslips, and settlement, and stop treating the person as current headcount. Deleting the row is how duplicate joiners and missing payroll history happen later.

Status lives on the employee record in the system of record. It is not a shared-drive folder named “Alumni,” and it is not the Full & Final process. Settlement has its own owner: the Full and Final settlement process. This article is the taxonomy of the people row those processes read.

The employee management process is how you create and maintain records. Dayzen employee lifecycle is the commercial home for later events after join, including exit. Dayzen employee management is where profiles, directories, and structure sit. Use those pages for product and process depth; use this page to decide what each status is allowed to mean.

Why the three labels get mixed

Spreadsheets invite deletion: hide the row, or move it to another tab, and the “active list” looks clean. An HRMS that is actually a system of record cannot work that way. Attendance, leave, payroll calculation, assets, and rehire checks all need to find the same person later. If the identity vanished, teams recreate it — often with a new employee ID — and you now have two histories that will never add up.

The opposite mistake is leaving everyone “active” forever so that reports stay simple. Then managers see people who have left, payroll includes names that should not be in this month’s run, and the org tree still hangs reports under an exited manager.

A third mistake is using “inactive” as a junk drawer: not yet joined, on notice, on sabbatical, contractor paused, and exited-but-we-might-rehire — all in one flag. If inactive does not have a written meaning in your team, do not use it. Two statuses (active and exited) plus a joining pipeline are cleaner than a vague middle.

What this page will not conclude

How long you must retain employee data, when you may delete it, and what Indian privacy or labour rules require in your situation are legal and policy questions. They are not answered here as law. Confirm retention with qualified counsel and your own policy. Operationally, “do not delete the row to tidy the directory” is a data-quality rule, not a retention statute. Dayzen is not offering a legal hold product claim on this page.

Active: currently employed

Active records belong in headcount, manager team lists, attendance and leave queues, and payroll for the periods they worked. They have a current department, designation, and reporting manager. They should appear in the searchable directory’s default “people we employ” views.

Joining date is a field on an active record, not a reason to keep someone in a candidate-only limbo after they have been activated. If hire-to-activate is still in progress, they may not be active yet — that is onboarding, not an inactive employee. Do not mark a delayed joiner inactive as a workaround; keep them in the pipeline until activation or a withdrawn offer.

Employee records in Dayzen are the shared foundation for recruitment handoff, onboarding activation, and payroll. Active status is how other modules know the identity is in play for current operations.

Inactive: a reversible pause you must define

If you use inactive, write down what it means. Typical operating holds include a long unpaid absence you still treat as employment, or a pause you do not want in daily manager queues but have not ended as an exit. The test is reversibility: you expect to set the person back to active on the same employee ID without treating them as a new hire.

Inactive should not mean:

• Exited, because someone was uncomfortable choosing a leaving date.
• Not yet joined, because onboarding was slow.
• Duplicate, because you found two rows and froze one without merging.
• Contractor versus employee, unless you have a separate, documented use of the flag.

Vague inactive flags confuse payroll. A person who is still employed may still need payslips, or may need to be excluded from this month’s run. That is a pay-period decision sitting on top of status — not a reason to invent a fourth unofficial label in a spreadsheet. If payroll and HR disagree on whether inactive people should be in the directory default view, write the rule once.

If you cannot explain inactive in one sentence, stop using it until you can.

Directory views versus the underlying row

HR still needs to find inactive people. Hide them from “current team” and from org-tree nodes that should only show people in seat. Do not hide them from search when an admin is doing a rehire or a correction. The status field drives the view. The row remains.

Exited: employment ended; the record stays

Exited means there is an end of employment on this identity: a leaving date, and a status that takes the person out of current headcount. Payslips already issued, attendance already closed, documents already stored, and asset history still belong to that person. The profile should remain, with history, documents, and (where you used them) assigned-asset views showing what was issued and returned.

They should disappear from current-headcount views and from manager queues. They should not disappear from history. Payroll, Full & Final, and rehire checks need the record to exist with an exited status.

Do not delete exited people to “clean the directory.” Cleaning is a filter. Deletion is amnesia.

Exited is not Full & Final

Status says the employment ended. Full & Final is the settlement process: calculations, recoveries, letters, and close-out steps your organisation runs after notice or termination. You can have an exited record whose settlement is still in progress, or a settlement checklist that is complete while the people row stays exited forever.

Do not duplicate that process here. Follow the Full and Final settlement process guide for the work itself. On the record, you need a status and dates that other modules can read. Lifecycle events after join — including exit — belong with employee lifecycle as the product surface, not as a second FNF article.

If someone is on notice but still employed, they are typically still active until the last working day your policy uses. “Serving notice” is a lifecycle fact, not automatically an exited row. Mixing notice with exited too early pulls them out of attendance and leave while they are still working.

What each status should change in the system

Status	Current headcount and org tree	Manager operational queues	History, payslips, documents	Typical next event
Active	Included	Included	Growing with employment	Transfer, leave, or later exit
Inactive (if used)	Usually excluded from “in seat” views	Usually excluded	Retained; employment not ended	Return to active, or convert to exited if employment actually ends
Exited	Excluded	Excluded	Retained on the same identity	Settlement process; possible later rehire on the same person

If a cell in that table is unclear in your HRMS, name the rule in your operating notes. Do not rely on whoever last edited the sheet.

Rehire, duplicates, and the temptation to start over

When an alumnus returns, search first. An exited record is the right place to resume identity: same person, new active period, with history still attached. Creating a brand-new employee because the old row “looks messy” is the duplicate-person failure mode. That failure is covered in the sibling article on preventing duplicate records at join; the status lesson is only this: exited is not a reason to pretend the person never existed.

If you find two rows — one active, one exited — for the same human, do not delete the exited one as a shortcut. Decide which identity is authoritative, then stop using the extra row. Search-before-activate at join is how you avoid the mess; status discipline is how you avoid creating it at exit.

Org tree, managers, and exited people

Current reporting lines should not point at exited managers. Reassign direct reports as part of the exit event, with dated assignment history so the past remains explainable. The org-chart-after-transfers how-to is about moves among the living; the same tree still needs a living parent after someone leaves. Ranks, departments, and designations stay as historical fields on the exited profile. They should not keep generating an “in seat” node.

Dayzen’s interactive org tree is a view of structure on employee records. Status is how you keep that view from treating alumni as today’s team.

Payroll and time without rewriting the past

Closed pay periods and attendance already processed should remain attributable to the person who worked them, even after exit. Changing someone to exited should remove them from the next operational cycle, not erase the last one. If a correction is needed, it is a payroll or time correction against the existing identity — not a new employee created so the old months can be ignored.

Inactive people, if you use the flag, need an explicit payroll rule: included, excluded, or included only for specific components. Silence here is how a “pause” becomes an unexpected payslip or an unexpected gap.

A short operating habit

1. Default directory views show active people (and only the inactive holds you intentionally include).
2. Admin search can still find exited and inactive rows.
3. Exit sets status and leaving date; it does not delete the profile.
4. Settlement follows the Full and Final process; it does not replace status.
5. Rehire searches exited records before anyone issues a new employee ID.
6. Retention and deletion requests go through policy and counsel — not through an informal “remove from HRMS” click.

Keep the taxonomy small and enforced. Employee profiles with history, documents, and assets only help if the row is still there to hold them after the person has left the building.