A new employee arrives on a Monday morning. Their manager is expecting them, and HR has sent a welcome email. But the laptop has not arrived, the account for the main business system has not been created, and payroll does not yet have their bank details because the form was sent to a personal email address that went unchecked. The first day is spent waiting, and the first week is spent catching up.
Situations like this are common, and they are rarely the fault of any one team. They happen because onboarding is not really one process owned by one team. It is a series of tasks distributed across HR, IT, finance, facilities and the hiring manager, each tracked in a different place and triggered in a different way. When those tasks are not connected, delays and gaps are almost inevitable.
Why onboarding breaks down
In many organizations, onboarding starts when HR records an accepted offer. From there, information travels by email: a message to IT asking for equipment and accounts, another to finance for payroll setup, another to facilities for a desk or access card, and a note to the manager to plan the first week. Each recipient handles the request within their own workload and priorities.
The difficulty is that nobody has a view of the whole. HR may not know that IT is waiting for a job title to determine which software licenses to assign. IT may not know the start date moved forward by a week. The manager may assume everything is in hand because nobody has said otherwise. Each team completes its own part as well as it can, but the handoffs between them are informal and fragile.
- Start dates and role details change after the initial request, and not every team hears about it.
- Requests are sent by email and tracked by memory rather than in a shared system.
- Access requirements depend on the role, but the mapping from role to access is undocumented.
- No one is responsible for confirming that everything is ready before the first day.
Onboarding as a single workflow
The shift that makes the biggest difference is conceptual before it is technical: treating onboarding as one workflow with one owner, even though many teams contribute to it. The workflow has a clear trigger, typically the signed offer recorded in the HR system, and a clear end state, such as the new employee having everything they need to work productively by the end of the first week.
Between those points sit the tasks for each team, with dependencies made explicit. IT cannot provision the right accounts until the role is confirmed. Payroll setup requires tax and bank details. Facilities needs the office location and start date. When these dependencies are written down, it becomes clear which information must be captured early and which tasks can run in parallel.
When every team owns a piece of onboarding and no one owns the whole, the new employee is the one who discovers the gaps.
What can be automated
Once the workflow is defined, much of the coordination can be automated. The HR system, as the source of truth for employee data, can trigger tasks in other systems automatically when a new hire is recorded. Account creation in the identity directory, license assignment based on role, equipment requests to IT, payroll record setup and facilities access can all be started from the same event, using the same data.
Automation also helps with changes. If the start date moves, every dependent task should be updated at once, rather than relying on HR to email each team again. If the role changes, the access profile should change with it. And as the start date approaches, the workflow can check whether all tasks are complete and alert the owner if something is outstanding, while there is still time to resolve it.
Not everything should be automated. The manager’s plan for the first week, introductions to colleagues and conversations about expectations are human work. The aim is to remove the administrative coordination so that the people involved can focus on the parts of onboarding that shape how a new employee experiences the company.
Role-based access and consistent data
One of the most useful artifacts in onboarding automation is a simple mapping from roles to access requirements: which systems, which permission levels, which equipment. In many companies this knowledge lives in the heads of IT staff, who work it out case by case. Writing it down makes provisioning faster and more consistent, and it also makes offboarding safer, because the same mapping tells you what needs to be revoked when someone leaves.
Consistent data matters just as much. If the employee’s name, title, department and manager are entered separately into several systems, small differences creep in and cause problems later in reporting, approvals and access reviews. Capturing these details once in the HR system and distributing them automatically keeps every system aligned.
The same logic applies to moves and exits
Once onboarding works as a coordinated workflow, the same structure extends naturally to internal moves and departures. A promotion or team change may require new access and the removal of old permissions. A departure requires equipment return, account deactivation, final payroll and handover of responsibilities. These processes are often even less structured than onboarding, and the risks of getting them wrong, such as former employees retaining system access, are significant.
Where to start
Gather representatives from HR, IT, finance, facilities and a couple of hiring managers, and walk through the last few hires together. List every task, who performed it, what information they needed and when they received it. Mark the dependencies and the points where something was late or missed. Agree on a single owner for the end-to-end workflow and a clear definition of “ready for day one.” From there, the first automation step is usually straightforward: trigger each team’s tasks from the HR system, using the same data, at the moment the offer is accepted.