Employee Onboarding and Offboarding Workflows with HaloESM
November 11, 2026
It is 8:40 on Monday morning. The new financial analyst is standing at the front desk holding a printed offer letter. Her manager is in a meeting. HR sent the welcome email on Friday, but IT never saw the hire, so there is no laptop. Facilities does not have her name, so there is no access pass. Finance was not told, so her cost center does not exist yet. Three teams did their jobs. Nobody ran the process.
Offboarding fails in the quieter direction. A sales engineer resigns and HR closes the file. Two months later someone notices that his accounts are still active, his laptop is still sitting in a branch office, and a supplier contract still lists him as the approver. Both stories share one cause. For the employee, joining and leaving are single events. For the company, each one is a set of separate tasks owned by four or five departments that rarely look at the same screen.
This article explains how to design employee onboarding and offboarding workflows that cross HR, IT and Facilities, where those workflows usually break, what the breakage costs, and how HaloESM runs the whole sequence from one place. We start with the problem and the cost, because the design only makes sense once you see where the hours and the risk actually go.
Most companies do not lack onboarding steps. They lack an owner for the sequence. HR owns the employment record, IT owns accounts and devices, Facilities owns desks and access, Finance owns cost centers and expense cards, and the hiring manager owns everything that is left. Each team has its own checklist, usually in its own tool, and the connections between those checklists live in email threads and in the memory of one coordinator.
When a request passes from HR to IT, it changes shape. HR writes "new hire, marketing, starts the 18th." IT needs a role, a location, a device type and a list of applications. Someone has to translate, and the translation is where information is lost. The same happens between IT and Facilities: a laptop is ready, but the desk is not, or the desk is ready and the building access request is still waiting for a manager signature.
The result is a process that runs on follow-up messages. Coordinators ask "did you get my email?" more often than they do actual provisioning. This is the same pattern we describe in our comparison of ITSM and ESM: a process that is simple inside one team becomes slow and fragile the moment it crosses a team boundary, because the tools and the ownership stop at the boundary.
The visible cost is lost productivity. A new employee without equipment or access spends the first days waiting, and the manager spends those days improvising. The less visible cost is the time of the people who chase: HR business partners, IT coordinators and office managers who each spend part of their week asking other teams where things stand. None of that time shows up on a dashboard, so none of it gets managed.
The costs on the leaver side are different and often larger. An account that stays active after someone leaves is an access risk. A device that is never recovered is a lost asset. An approval right that is never reassigned is a control gap that an auditor will eventually find. These are not exotic failures. They happen whenever offboarding depends on someone remembering to tell three other teams.
Consider a company that hires five people a month across three sites. If each hire needs eight handoffs between four teams, that is forty handoffs every month, and each one is a chance for a missed message. The numbers are illustrative, but the arithmetic is the point: handoffs grow with hiring volume, while the capacity of the coordination team stays where it was.
There is also the experience of the employee. A first week where the basics do not work sends a message about how the company runs, and a departure handled sloppily sends another one, to the person leaving and to the colleagues watching. Neither message is what leadership intended.
A joiner workflow is not a long checklist. It is a short sequence of stages, each with a clear owner, a clear trigger and a clear definition of done. The stages below fit most organizations, and you can adapt the details to your size and your industry.
Everything starts with a trigger. In most companies it is an approved offer or a signed contract, and it is entered by HR. The trigger should capture the information that every downstream team needs: role, department, manager, location, start date, employment type and any special equipment or access requirements. If HR has to enter this once and every later team reads it from the same request, the translation problem from the previous section largely disappears.
Approvals that belong to this stage, such as budget confirmation or manager sign-off for non-standard equipment, should happen here and not later. A late approval blocks a task that someone else is already waiting for.
IT receives a task, not an email. The task already contains the role and the start date, so the standard bundle of accounts, applications and hardware for that role can be prepared without a conversation. Requests that fall outside the standard bundle go through approval inside the same workflow, so the approver sees the context.
The important design choice is the due date. IT should not work to "as soon as possible" but to a date tied to the start date, for example two working days before day one. A date turns a vague request into a commitment that can be tracked.
Facilities needs the location and the start date, and in many cases the department so the desk lands in the right area. The tasks are simple: assign a desk or a locker, issue an access pass, add the person to the building system and, for field roles, prepare any uniform or safety equipment. They are simple, but they are the tasks most often missed, because Facilities is rarely on the distribution list for HR announcements.
The workflow does not end when the laptop is ready. The new hire needs a short list of things to do, such as accepting policies, completing mandatory training and meeting the team. The manager needs tasks too: a first-week conversation, objectives for the first month and a check-in. When these tasks live in the same workflow, HR can see at a glance whether the manager side is moving, and not only the IT side.
A joiner workflow is complete when every stage is closed and the employee confirms that they can work. Closing the workflow on the last task, not on the first reply, is what makes the process measurable.
Offboarding deserves more attention than it gets, because the consequences of a gap are worse and less visible. Nobody complains when an old account stays active. The problem is discovered later, usually by an audit or an incident.
The core of offboarding is a clean cut-off: accounts disabled on the right date, access passes cancelled, devices recovered and checked in, and assets recorded as returned. Each of these belongs to a different team, and each has a different deadline. Access should end on the last working day or earlier for sensitive roles. Equipment recovery can take longer, especially for remote employees, so it needs its own task with its own owner and a follow-up if nothing arrives.
This is where a connection between the workflow and the asset record matters. If the system knows which devices are assigned to the leaving employee, the recovery tasks can be generated from that list instead of from someone's memory.
Resignations, dismissals and disciplinary cases are not information for everyone. An offboarding workflow has to move tasks between teams without exposing the reason for the departure. The design rule is that each team sees the task it needs to perform, such as "disable accounts for this person on this date," and nothing more. HR keeps the case details restricted to HR. Agree in advance which fields each team needs, and have HR and Legal review that list before the first hire goes through the workflow.
Leavers also hold things that are not assets: ownership of shared mailboxes, approvals in finance flows, customer relationships, scheduled reports and recurring tasks. A good offboarding workflow includes a handover step for the manager, with a short list of what needs a new owner. The step is cheap and it prevents the supplier-contract problem from the opening of this article.
An internal transfer is a small offboarding and a small onboarding at the same time. The employee keeps some access and loses some, changes cost center, and may change location. Companies that only design for joiners and leavers tend to discover that their movers accumulate permissions over the years. If you build the two main workflows well, a mover workflow is mostly a recombination of stages you already have.
Before choosing any tool, it helps to agree on a few design rules. They are the same whether you run the workflow in a spreadsheet or in a platform, and they decide whether the workflow survives contact with real hiring volume.
The most important rule is that the whole sequence is a single request with a single history. HR starts it, and the tasks for IT, Facilities and Finance are part of the same record. Everyone can see the same status. This is the difference between running a process and relaying messages about a process.
Cross-department does not mean one-size-fits-all. IT needs a device form, Facilities needs a location form, and HR needs fields that the others should not see. Each team should keep its own intake form, its own approval rules and its own target for completion. The workflow connects these pieces without forcing them into a single template. This is the same logic we apply to service catalogs for legal, finance and facilities, where each department keeps its own offerings under one portal.
Pick two or three measures and track them from the first month. Useful ones are the share of new hires who have everything on day one, the time between the last working day and the closing of the offboarding workflow, and the number of tasks that went past their due date, by team. These numbers turn onboarding from an anecdote into something you can improve, and they show which team needs help.
The most reliable way to fail is to model every role and every site on the first attempt. Start with the most frequent joiner type in one location, run it for a month, and fix what breaks. Then add the leaver workflow, then the exceptions. The same phased logic is behind our guidance on building finance and legal portals in four weeks: small, working and measured beats complete and late.
Real hiring is full of exceptions: a hire who starts a week early, a role that needs special software, a manager who is on leave when the approval arrives. A workflow that only handles the standard case sends people back to email the first time reality differs. Decide in advance who can approve an exception, who is the backup when an approver is absent, and what happens when a task passes its due date. An escalation rule that alerts the next person is more useful than a report that explains the delay afterward.
HaloESM covers HR onboarding and offboarding as a department-level capability, alongside facilities maintenance and access passes, purchase requests and supplier onboarding. Here is how its capabilities map to the workflow described above.
Yes. In HaloESM, requests route across IT, HR, Facilities, Finance and other departments, and each team completes its stage before the workflow advances. A joiner request can therefore pass through HR, IT and Facilities, and every team works on the same record. Workflows in Halo define the process a ticket follows before it can be marked resolved, and they often include approval steps, so the approvals described in stage one sit inside the process instead of beside it. Each team keeps its own forms and SLA targets, so the shared record does not flatten how each department works.
Yes. Each department in HaloESM has its own service offerings, request forms, approval workflows and SLA targets, all reached through one portal. HR can collect the fields it needs, IT can ask for a device type, and Facilities can ask for a location, without a shared template that nobody likes. Administrators configure routing rules, approval chains, notifications and cross-team handoffs without developer resources. Because intake forms, approvals and targets are defined independently per department, a change to the Facilities form does not touch what HR collects.
Halo tracks hardware assets with make, model, serial number, location, assigned user and warranty status, and assets can be linked to tickets. Because each asset records its assigned user, the devices a leaver holds can be looked up and linked to recovery tickets, so recovery starts from a real list. Lifecycle stage tracking and end-of-life notifications then keep the equipment cycle clear after the device comes back, so a returned laptop is checked in and either reissued or retired deliberately.
Halo AI in service management shows knowledge suggestions to end users before they create a ticket, and a virtual agent is available for end users. Ticket triage across departments uses auto-classification. A new hire can find the answer to a basic question, such as how to connect to the office network, without waiting for IT to reply. The portal is customizable and mobile-responsive, so the same entry point works on a phone. Knowledge base content and request forms are configured through the no-code admin interface, which means HR can keep the new-hire material current without a developer.
Sensitive HR, legal and risk matters stay visible only to users with the right permissions, which is configured through role-based access control. Federated administration and sub-admin permissions let HR manage its own area while central teams keep control of the platform. Reporting is separated by department, so HR can track its onboarding measures without exposing them to every team. Data segregation options add a further layer where the organization needs one.
For a broader view of how ESM extends the same service standards beyond IT, see our guide to enterprise service management beyond IT. For the product itself, our HaloESM and Halo overview page describes the modules we implement.
Companies in Latin America face the same structural problem with a few local complications. Many operate across several countries, with sites that have different local managers, different labor rules and different languages for the people involved. A workflow that works in the head office can fail in a branch because the local steps are missing.
Labor regulations differ by country, and so do the documents and notifications that must accompany a hire or a departure. The practical approach is a common backbone with local steps. The backbone covers the stages in this article. The local layer adds the country-specific tasks, such as the paperwork that HR must file or the notice that Finance must send. HaloESM supports multi-site, multi-language and multi-team configurations, so the backbone can be shared while each country keeps its own steps.
Many Latin American companies hire in waves, for a new branch, a seasonal peak or a contract that starts suddenly. A manual process that copes with two hires a month collapses at twenty. A workflow does not remove the work, but it makes the work repeatable and visible, which is what a hiring wave requires. Distributed teams add a second factor: remote employees need equipment shipped and recovered, which is a task with a longer lead time and a higher chance of being forgotten.
In many organizations in the region, HR coordination runs through chat groups and personal follow-up, which works as long as the same two people are always available. The shift to a workflow is as much a cultural change as a technical one. At GB Advisors we offer consulting, customization and implementation for Halo with certified technicians, and we suggest starting with the process: who owns each stage, what counts as done and what the first measure will be.
Use this list to test whether your organization is ready to automate onboarding and offboarding, or to review a workflow you already have.
A checklist is a good start, and for a handful of hires per year it may be enough. The problem appears when the checklist has to cross teams. A checklist cannot remind IT that a date has passed, and it cannot show HR which stage is stuck. If your coordinator spends part of each week asking other teams for updates, you have already outgrown the checklist, whatever the hiring volume is.
Because the new hire is not an IT problem. IT is one stage in a process that also depends on HR, Facilities and Finance. Using an IT service management service desk for the IT stage and email for everything else keeps the handoffs where they were. The advantage of extending the same approach to HR and Facilities is that the whole process has one history and one status, which is the idea behind enterprise service management.
This is a legitimate concern and the answer is permissions, not avoidance. Sensitive HR matters should be visible only to the people who need them, and other teams should see tasks without the reasons behind them. Role-based access and delegated administration are the controls that make this possible, and they should be part of the design from the first day, not added after a complaint.
You do not need to redesign everything. Start with the most frequent joiner type in one location, run it for a month and adjust. The effort is the same effort your coordinators already spend chasing updates, redirected into a process that does the chasing for them. A short working session to map the current stages and owners shows quickly where the biggest gap is.
Employee onboarding and offboarding fail at the handoffs, not inside any one team. The fix is a single request with a single history, with each department keeping its own forms, approvals and targets, and with a clear owner and due date for every stage. On the joiner side this means a new hire who can work on day one. On the leaver side it means access closed, equipment recovered and ownership handed over.
HaloESM routes requests across IT, HR, Facilities and Finance, lets each team complete its stage before the workflow advances, keeps sensitive HR matters restricted, and ties assets to the employees who hold them. If you want to see how that would look with your own teams and sites, talk to GB Advisors and we will start from your current process.
