The connected HR lifecycle

BlueOneHR is not a set of separate tools glued together: a hire, an offer, an employee record, a payroll contract, an objective and a background-verification case all reference the same underlying data, in one system. This page follows one hire through that connected lifecycle — candidate, interview, offer and acceptance, employee record, a payroll contract an HR leader explicitly activates, an individual objective, and a background-verification case on a mock provider — and says, at each step, exactly what is real product behaviour and what is illustrative or mocked for the recording.

Illustrative demonstration prepared using publicly available company context and synthetic data. This video does not represent a production deployment, customer endorsement, or use of real employee data.

The connected HR lifecycle: hiring to workforce operations

The hire this page follows

Every screen below was recorded against a fresh, fictional company built for this walkthrough — Mumbai head office, a regional office, and a handful of departments spanning project delivery, MEP, EHS, tendering and estimation, HR and finance. Its name, its departments, its one example employee and every figure on screen are synthetic; none of it represents a real customer, a real headcount or a real payroll.

Candidate, interview and offer

A requisition's open position becomes a candidate in Recruitment's pipeline board, moving through stages such as Applied, Initial and Hired. An interview can be scheduled against the candidate at any stage. An offer is a separate record: it carries a position, a salary template and an annual CTC, and the platform's own compensation engine computes the monthly Basic/HRA package and freezes it with the offer — the breakdown shown on an offer is read-only from that point on. The candidate accepts (or declines) the offer from their own link, without signing in to the rest of the platform.

The protected handoff: offer to employee

Accepting an offer does not, by itself, create an employee. Converting a candidate is a single, guarded action that checks, in order: the offer is Accepted, the offer is effective (accepted and — where a signature is required — signed), and the candidate's onboarding hand-off has been consumed. Any one of those being missing refuses the conversion outright, with a specific reason, rather than creating a half-complete employee. Converting a candidate that does pass every check creates, in one step: the employee record, their work information (department, job position, reporting line), and a draft payroll contract built from the offer's frozen package.

A contract a person activates

A draft payroll contract does not pay anyone. Nothing in this chain auto-activates a contract — not the conversion step, and not Mitra. An HR leader reviews the draft against the offer it was built from and activates it explicitly; only an active contract with a positive wage is ever payable. That one explicit, human action is the point where "a person was hired" becomes "a person is on payroll."

Workforce operations continue from there

Once someone is an employee, the same record is visible to Performance (an individual objective can be set against them), and to a background-verification case, which in this recording used the platform's mock BGV provider — the case, its status and its audit trail are real BlueOneHR behaviour; no outside verification agency was contacted. Corporate learning assignment and ERP/payments integrations exist as real product surfaces but are shown only as capability boundaries in the video that goes with this page, not as completed third-party actions.

Where Mitra fits

Mitra opens alongside pages such as the Control Center and reads only what the signed-in person's own permissions allow, explaining rather than acting. It does not activate a payroll contract, approve an offer or convert a candidate. Every action described above — approving, sending, converting, activating — was taken by a named person, not by Mitra.