Four sequential stages, two roles with different authority, and a field-level audit trail — because in HR the argument is never “what is the status”, it's “who changed my CTC”.
Onboarding a hire touches an offer letter, four KYC documents, an HR approval and a joining confirmation. In practice each of those lived somewhere else — a mail thread, a shared folder, a spreadsheet — so the honest answer to “where is Arjun Mehta” was “let me check with someone”.
The second problem was quieter and worse. Offer terms get edited: CTC, grade, joining date, reporting manager. Those edits were invisible after the fact, which turns a routine correction into a dispute with no record.
So this wasn't a dashboard problem. It was a state machine and an evidence problem.
A checklist that can only be pending or done can never be finished for a hire who doesn't drive. Without an explicit “not required”, HR does what HR always does: marks it verified anyway, and the audit trail starts lying. Adding the state cost one extra chip per stage and saved the integrity of the whole record.
This is the real prototype below. Switch the role chip between HR Manager and Super HR Manager, open Arjun Mehta, click a KYC document, then open the audit trail.
Four stage columns, one row per person, so “where is everyone” is a single downward scan. Candidate and employee live in the same table — the distinction is a chip, not a separate screen.
Clicking a KYC document shows the extracted fields in a popup — masked Aadhaar, masked account number. Verifying shouldn't require downloading someone's identity documents to a laptop.
Super HR Manager sees the same record with the approval action unlocked and the fuller history. Same shell, so an HR Manager can be walked through it by their lead.
Most audit views say “Priya Sharma updated the record”. That is useless in the only conversation it exists for. Every event here carries the field name, the old value, the new value, the actor and whether the actor was a human or the system — and where one action changed two fields, both diffs sit inside a single event rather than reading as two separate edits.
It's a vertical timeline, not a table: a colour-coded marker rail carries the action type down the left, the date sits in its own narrow column, and the actor is attributed underneath the change rather than in a far-right column — so each event reads as one small paragraph of evidence.
Five of the twelve events, reproduced from the shipped build's own audit data — the full timeline is reachable in the live prototype above. The highlighted event is the one that justifies the screen existing; the two 11:45 AM events show a single approval action landing as two audited field changes.
There's no bulk action anywhere. A real HR Manager onboarding a cohort of twelve graduates will update the same stage twelve times, and I designed for the single-candidate case because that's the case that demos well. That's the honest gap.
Status vocabulary is design work, not data modelling. The difference between a record people trust and one they quietly work around came down to which words a status field is allowed to hold — and arguing for one extra one.
The same lifecycle from the other end: clearance, settlement, closure.