Joiner-Mover-Leaver Automation: Managing Employee Access Across Business Systems
How to automate joiner, mover and leaver access: HR as the source of truth, role-based access, SCIM provisioning, access reviews and offboarding evidence.
What should joiner-mover-leaver automation do?
Joiner-mover-leaver (JML) automation should take HR changes as the trigger, create or update the person in the identity provider, grant birthright access by role and location, route extra access through requests and approvals, remove old access when people move, disable accounts and sessions promptly when people leave, and record every change for audit. Periodic access reviews and segregation-of-duties checks catch what automation misses.
This guide is for IT, security and operations leads at organisations with dozens of business applications and people joining, moving and leaving every month.
Key takeaways
- Make the HR system the source of truth for who works here and in what role.
- Grant birthright access by role; request everything else with approval.
- On a move, remove old role access as well as adding new.
- On leaving, disable sign-in and revoke sessions and tokens, not just licences.
- Include non-SCIM applications through APIs or tracked tasks.
- Review privileged access regularly and record decisions.
Joiners, movers and leavers at a glance
| Event | Trigger | Actions | Main risk |
|---|---|---|---|
| Joiner | Hire confirmed in HR with start date | Create identity; assign role groups; provision apps; prepare device; activate on day one | Access too early, or too late to be productive |
| Mover | Role, team, location or manager change | Add new role access; remove old role access after an agreed overlap; re-approve exceptions | Privilege creep |
| Leaver | Termination date and time in HR | Disable sign-in; revoke sessions and tokens; deprovision apps; transfer data ownership; recover devices | Former staff retaining access |
| Contractor or temporary staff | Engagement record with end date | Time-limited access; sponsor; automatic expiry | Accounts that never expire |
Reference architecture
The common pattern is HR system to identity provider to applications. The identity provider (for example Microsoft Entra ID, Okta or Google Workspace) holds groups that represent roles, and pushes accounts to applications through SCIM (RFC 7644) or connectors. Lifecycle features such as Microsoft Entra lifecycle workflows can run tasks before a start date or after a leave date. For sign-in and provisioning detail, see enterprise SSO implementation.
| Layer | Responsibility |
|---|---|
| HR system | Who the person is, role, department, location, manager, start and end dates |
| Identity provider | Accounts, authentication, groups, conditional access, session revocation |
| Role model | Mapping from HR attributes to groups and application entitlements |
| Provisioning | SCIM, APIs or tracked admin tasks per application |
| Requests and approvals | Access beyond birthright, with owner approval and expiry |
| Reviews and audit | Periodic certifications, segregation-of-duties checks, change logs |
Designing the role model
Start small. Define birthright access that everyone in a department or location gets, such as email, chat and the intranet, then role bundles for common jobs. Keep exceptions as requests with an expiry rather than adding more roles. Name groups by purpose, give each application entitlement an owner, and keep the mapping in configuration that people can review. For product-side permissions inside your own SaaS, see SaaS roles and permissions.
Leavers: what complete offboarding looks like
- Disable the identity at the agreed date and time, or immediately for urgent exits.
- Revoke active sessions, refresh tokens and app passwords.
- Deprovision accounts in every connected application, including non-SCIM ones.
- Rotate shared secrets and credentials the person knew.
- Transfer ownership of files, mailboxes, repositories and automations.
- Recover devices and wipe or reassign them.
- Record completion per system, with exceptions followed up.
Access reviews and segregation of duties
Automation keeps access aligned with HR data, but it cannot judge whether someone still needs an exception or whether two permissions together are risky. Periodic access reviews ask managers or application owners to confirm or remove access. Segregation-of-duties rules flag combinations that let one person complete a sensitive process alone.
| Combination | Why it is risky | Typical control |
|---|---|---|
| Create supplier and approve payment | One person could pay a fictitious supplier | Block, or require a second approver |
| Deploy code and approve own changes | Unreviewed changes reach production | Branch protection and separate approvers |
| Administer identity and audit logs | Changes could be hidden | Separate admin roles; immutable logs |
Evidence for security frameworks
Joiner, mover and leaver records help show user access control in frameworks such as the NCSC's Cyber Essentials and ISO/IEC 27001. Keep logs of who approved what, when access was granted and removed, and review outcomes. Software produces the evidence; your policies and assessors decide what is enough.
Hypothetical example: a 300-person services firm
This example is hypothetical. A professional services firm onboarded people by email checklist and found former contractors still active in its project tool months after they left. It connected its HR system to its identity provider, defined birthright and role groups for five job families, turned on SCIM for the applications that supported it and created tracked tasks for three that did not, and set contractor access to expire on the engagement end date. Quarterly reviews now cover finance and admin roles.
Common mistakes
- Starting from the identity provider instead of clean HR data.
- Only adding access on a move.
- Disabling licences but leaving sessions and tokens active.
- Ignoring applications without SCIM.
- Hundreds of roles that nobody can review.
- Access reviews that show entitlement codes reviewers cannot understand.
Sources
Standards and platforms: RFC 7643 (SCIM core schema); RFC 7644 (SCIM protocol); Microsoft Entra lifecycle workflows; NCSC: Cyber Essentials.
Accessed 10 October 2026.
Conclusion
JML automation works when HR data is trustworthy, roles are few and owned, moves remove old access, leavers lose sessions as well as accounts, and every application is covered by SCIM, an API or a tracked task. Access reviews and segregation-of-duties checks cover the judgement automation cannot.
Still offboarding people with a checklist?
ZSpace Labs is a remote-first technology studio that works with clients globally on identity integrations and internal tools and workflow automation. If it would help to map your HR, identity and application flows, we are happy to talk it through.
Common questions.
The process of giving people the right access when they join, changing it when their role changes, and removing it when they leave. Automating JML means HR events trigger those changes in the identity provider and connected applications, with approvals and records.