Direct answer
Each new hire creates requests for several teams: equipment, accounts, access, a desk or workspace, introductions. Each team handles its part, but nobody sees the whole picture, so a hire arrives with one thing missing. Tracking onboarding requests means one record per hire that generates the set of requests, gives each an owner, and shows what is still open. It is a scoped internal tool built in your systems. It is not an HR product and does not handle payroll or contracts.
The trigger
Something has to start the process, and it should be a single event, such as a hire being marked as confirmed by the person who owns that decision. The trigger creates the onboarding record and its requests automatically, so nobody depends on remembering to send emails. Who is allowed to trigger it is a rule for your organisation.
The request set
The set of requests depends on the role and your organisation. A typical structure might include:
- Equipment for the hire's team
- Accounts and access in the tools the role uses
- Workspace or location arrangements
- A first-week plan owned by the line manager
- Introductions and required training
Owner and dependencies
Every request has one named owner or a team queue with a named lead. Some requests depend on others: access cannot be granted before an account exists. Record those dependencies so a blocked request shows as blocked, with the reason, instead of appearing simply late. Keep the model simple; a few dependencies are usually enough.
What done means
Agree what done means for each request. Handed over is not the same as confirmed working. A good rule is that the new hire or their manager confirms the item, so that a request closes on evidence, not on the owner's say-so. The onboarding is complete when every request is closed, and that state is visible on the hire's record.
The late-item view
Give the person coordinating onboarding a single view of open and blocked requests across all hires, grouped by owner. What counts as late is relative to the start date, and the threshold is your call. For general internal requests the same idea is described in internal request portal.
The offboarding mirror
Leaving mirrors joining: equipment to return, accounts to close, access to remove. The same record structure works in reverse, with the same owners and the same visibility. Access removal in particular benefits from a checklist that is confirmed rather than assumed. See AI onboarding automation for the customer-facing counterpart.
What stays in HR software
Employment contracts, payroll, personal records and benefits belong in the systems designed for them. The onboarding tracker links to a hire by an identifier and holds only what the requests need. We do not replace an HR system or claim to handle its data.
Questions
Is this an HR system?+
No. It tracks the internal requests a hire creates across teams. Contracts, payroll and personal records stay in your HR tools.
Can it connect to our existing tools?+
It can be built to create requests and read status from the tools you use. Which connections are practical depends on those tools and is confirmed during scoping.
How is a request closed?+
By confirmation from the hire or their manager, not just by the owner marking it done. That keeps the closed state reliable.
Does it work for offboarding?+
Yes. The same structure runs in reverse for equipment returns, account closure and access removal.