User Onboarding and Offboarding Workflow for MSPs and IT Teams

A good user onboarding and offboarding workflow turns every starter or leaver request into the same verified sequence: confirm the request is genuine, apply the client's role template, prepare account, licence and group changes for technician approval, set up or collect devices, then record every step. Offboarding adds one rule above all others: list every system the person could reach and remove each one.

For MSPs and internal IT teams, starters and leavers are some of the most frequent tickets, and some of the easiest to get slightly wrong. A new hire arrives without access to the shared drive. A leaver's account is disabled, but their access to the finance app, which uses a separate login, stays active for months. Neither is dramatic on the day. Both cause problems later.

This guide walks through the workflow stage by stage, with what can run automatically, what needs a technician's approval and what always stays with a named person.

Why starters and leavers go wrong

The same causes come up again and again:

• Late or vague requests. HR emails "Sam starts Monday" on Friday afternoon, with no job role or manager.
• No role templates. Each technician builds accounts from memory, so two people in the same role end up with different access.
• Access spread across systems. Microsoft 365 or Google Workspace is only part of it. Line-of-business apps, VPNs, password managers, building access and SaaS tools with their own logins all need handling.
• Offboarding treated as "disable the account". Mailbox handling, file ownership, device return, licence reclaim and shared credentials get missed.
• Weak records. When an auditor or client asks who removed access and when, the answer is buried in ticket notes.

The onboarding workflow, stage by stage

Stage 1 and 2: Take the request and verify it

Use a structured form, not email, so every request carries the same fields: full name, job title, department, manager, start date, work location, required apps and any equipment. A form submission can create the ticket in your PSA directly.

Then verify. Starter and leaver requests are an obvious target for social engineering, because a fake starter request can create a working account for an attacker. Check the requester against the client's documented list of people allowed to request access, and confirm out of band, for example by calling a known number, when the request comes from an unexpected person or asks for elevated access.

Stage 3: Ask for missing details automatically

If the role, manager or start date is missing, the workflow sends the requester a short list of what's needed and reminds them on a schedule. Technicians stop chasing, and the ticket clearly shows it's waiting on the client.

Stage 4: Build the plan from a role template

Role templates are the core of the whole process. For each client, document what each role gets:

• account type and licence
• security and distribution groups, shared mailboxes and Teams or shared drives
• line-of-business apps and their permission levels
• device type and standard software
• MFA method and any conditional access policies

The workflow reads the request, picks the template and prepares a draft change list. Bulk starters, such as a seasonal intake, often arrive as a spreadsheet; converting it to structured data with a tool like our free CSV to JSON converter makes it easier to validate before anything is created.

Stage 5: Apply the approved changes

A technician reviews the draft and approves it. Standard changes can then be applied through the Microsoft 365 or Google Workspace admin APIs using a service account with only the permissions it needs. Anything involving admin roles, finance systems or other privileged access should be applied by a named person, never by the automation alone.

For first sign-in, avoid emailing passwords in plain text. Microsoft's Temporary Access Pass or a one-time link through your password manager is safer. If you must set an initial password, make it long and random, for example with the password generator, and force a change and MFA enrollment at first sign-in.

Small touches matter too. Generating a consistent email signature from the client's template with an email signature generator saves the new starter guessing.

Stage 6 and 7: Device and confirmation

Assign a device from stock, enroll it in your device management tool so policies apply automatically, and track delivery. When everything is done, send the requester a short summary of what was set up, and update the user record in your documentation platform.

The offboarding workflow: where the risk is

Offboarding deserves more care than onboarding, because a missed step leaves access open rather than closed.

1. Verify the request with the same authorized-requester check. Be especially careful with urgent or confidential leavers, where HR may need you to act at a specific time.
2. Agree the timing. Access removal at the end of the last working day is common; immediate removal may be needed for dismissals. The client decides, and the ticket records the decision.
3. List every system. The workflow pulls the user's groups, licences, app assignments and documented app access, plus anything their role template granted. Shared accounts and passwords they knew go on the list too.
4. Block sign-in and revoke sessions. Disabling the account isn't always enough on its own if active sessions and tokens remain valid, so revoke them as part of the same step.
5. Handle the mailbox and files. Convert to a shared mailbox, set forwarding or an auto-reply, or export and retain, as the client instructs. Transfer file ownership before deletion.
6. Remove access everywhere else. Line-of-business apps, VPN, password manager vaults, SaaS tools, building access and MFA devices. Each removal is ticked off in the ticket.
7. Rotate shared secrets the person knew, such as shared mailbox passwords or Wi-Fi keys, where the client agrees.
8. Recover devices and wipe them according to policy.
9. Reclaim licences once data handling is complete, so the client stops paying for them.
10. Confirm and record. The requester gets a summary, and the ticket shows who did each step and when.

The automation's job is to make sure nothing is forgotten: it builds the list, tracks completion and chases the last open item. Decisions about data retention, legal holds or what a manager can access are confirmed with the client.

What stays with people

Following the same boundaries Make It Flow uses for MSP automation:

• Automate: matching requests to clients and users, chasing missing details, building change lists from templates, tracking completion and drafting confirmations.
• Review: every account, group and licence change before it's applied, and billing changes from licence reclaim.
• People decide: privileged access, security incidents (a hostile leaver is an incident, not a ticket), mailbox and data retention, and anything outside the documented runbook.

Compliance: check the rules where you operate

Timely access removal shows up in many frameworks and laws. A few examples:

• United States: for healthcare clients, the HIPAA Security Rule includes termination procedures for ending access to electronic protected health information when someone leaves. It's an addressable specification, so the client must implement it or document a reasonable alternative.
• United Kingdom: the Cyber Essentials user access control requirements expect accounts to be removed or disabled when no longer required.
• Australia: the Essential Eight's restrict administrative privileges strategy includes, at higher maturity levels, disabling privileged access after a period of inactivity and requiring periodic revalidation.
• UK, EU and elsewhere: GDPR's security and data minimization principles apply to employee data held in these systems, and Canada's PIPEDA and Australia's Privacy Act set similar expectations for safeguarding personal information.

Which of these apply depends on your clients' sectors and locations. Check the rules where you and your clients operate, and agree in your contract who is responsible for each step.

FAQ

What should an IT offboarding checklist include?

At minimum: verify the request, block sign-in and revoke sessions, handle the mailbox and files as the client instructs, remove access to every app and system, rotate shared secrets, recover and wipe devices, reclaim licences and record each step with who did it and when. Base the list on the user's role template and documented access.

How quickly should access be removed when an employee leaves?

Usually at the end of the last working day, or immediately for dismissals and high-risk leavers. Some frameworks expect access to be removed promptly without fixing an exact time. Agree the standard timing with each client in advance, and make sure urgent requests have a fast, verified path.

Can user onboarding be fully automated in Microsoft 365?

Much of it can be prepared automatically from role templates, including account creation, licences and group membership. A technician should still review changes before they're applied, and privileged access needs a named person. Requests should also be verified first, because a fake starter request could create an account for an attacker.

What is a role template in IT onboarding?

A documented list of what each job role receives: licence, groups, shared mailboxes, apps and permission levels, device and security policies. Templates make onboarding consistent and give offboarding a starting list of access to remove. They need reviewing whenever a client adds systems or changes roles.

How do MSPs verify starter and leaver requests?

By checking the requester against the client's documented list of authorized contacts and confirming unusual requests out of band, such as a call to a known phone number. Requests that ask for admin rights, come from unknown senders or feel unusually urgent deserve extra checks before anything is changed.

What happens to a leaver's mailbox and files?

That's the client's decision, usually based on its retention policy and any legal needs. Common options are converting the mailbox to a shared mailbox, setting forwarding or an auto-reply, or exporting and retaining it. Files should be transferred to a manager or team owner before the account is deleted.