User provisioning process flowchart (joiner, mover, leaver)
User provisioning process flowchart: HR event, identity created in the directory, credentials and MFA, role entitlement bundle, owner approval for privileged access, downstream accounts, verification and recertification.
How it works
Rename the lanes to your own roles
Replace HR or sponsor, Identity team, Line manager, Entitlement owner and Security with the roles you actually have. Keep HR and sponsor in one lane on purpose: they are the same job done for different populations, and splitting them is how non-employees end up with nobody accountable for them. The entitlement owner lane is the one most organisations find they have not filled. If you cannot name an owner for your privileged entitlements today, that gap is a finding rather than a drafting problem, and the lane should stay in the chart, visibly empty, until it is closed.
Declare your source of record, and what it is not
The chart assumes an authoritative feed of joiners, movers and leavers. Write down which system that is, which fields it carries — job role, manager, start date, effective date of a change, last day — and how quickly a change appears in it. Then write down who is not in it. Contractors, board members, agency staff, interns and machine identities usually are not, and every one of them needs a register and a sponsor of its own before the rest of the process can run.
Write the entitlement bundles before you publish
"Derive the role entitlement bundle" is inert until the bundles exist. Start with the ten roles you hire into most often and write down what each genuinely needs on day one. Where you have sign-in or last-used data, build from what current holders actually use rather than from what they hold; the gap between the two is usually wide, and it is the whole reason the bundle is worth writing. Keep each one a floor rather than a ceiling, so anything outside it stays visible enough to be worth asking for.
Set the bar for owner approval
"Inside the standard bundle?" only works if the criteria sit beside it. Typical triggers for the approval branch are administrator and root rights, production access, payment or payroll systems, personal and health data, and anything that can change another person's access. Test that list against last quarter's grants before you publish it: a criterion that catches most of them is not a criterion. If everything routes to an entitlement owner, approvals arrive faster than anyone can read them and the control becomes a queue people learn to click through.
Make the mover removal a tracked obligation
"Revoke the superseded entitlements" is the step that decides whether access accretes in your organisation. Give it the same ticket, the same owner and the same deadline as the grant, and close the mover event only when both halves are done — a ticket that closes on the joining half is the mechanism by which removal never happens. The chart puts the comparison with the line manager rather than the identity team on purpose: the team can produce the list of differences, but only the manager knows whether an entitlement is genuinely superseded or still needed for a handover.
Walk it through with the people who run it, then publish a version
Settle the two branches nobody owns by default before you publish. Decide who may invoke break-glass out of hours and who reads the session log afterwards, and decide who acts on a "Drifted" answer at recertification and by when, since a review that produces a list nobody revokes from is worse than no review at all. Then take the chart to a service desk engineer, a line manager who has recruited recently, and whoever last ran an access review, and correct it to what really happens. Publish the corrected version, keep its predecessors readable, and cite it from your access control policy.
Frequently asked questions
What are the steps in a user provisioning process?
Take a joiner, mover or leaver event from the system of record; decide whether the person is an employee or a non-employee, and give non-employees a sponsor and an expiry date; create or match an identity in the directory with an identifier that is never reused; issue credentials and enrol multi-factor authentication against that identity; derive the entitlement bundle for the job role; auto-provision everything inside that bundle and route privileged or out-of-bundle entitlements to the entitlement owner for approval; create accounts in the downstream systems, both the automated ones and the manual queue; verify that what the systems actually grant matches what was asked for; have the line manager confirm it; and record the entitlements against the identity. After that the process keeps running: a move re-derives the bundle and revokes what the old role no longer justifies, a leaver is disabled and handed to removal, and recertification checks periodically that the entitlements and the role still agree.
What is a birthright or role-based entitlement bundle?
It is the set of access a job needs on its first day, attached to the role rather than to the person: mail and calendar, the intranet, the core line-of-business systems for that function, the shared drives for that team. Because it is derived from the job role, it can be granted without an approver in the path, which is the point — it removes the routine grants from the approval queue so the exceptions get read properly. Two rules keep bundles honest. Build them from what the job requires, never by exporting the access of the person who last held it, since that copies every accumulated extra along with the necessities. And give each bundle a named owner and a review date, because an unowned bundle only ever grows: every request that could not be refused gets added to it, and within two years it grants far more than any single job needs.
How is a user provisioning process different from an access request process?
They meet in the middle and own different halves. The access request process at /templates/access-request-process starts with a person already in post who needs one more system: they raise a request, the line manager and the system owner approve it, and it is provisioned and later recertified. The employee access request process at /templates/employee-access-request-process covers the same request when an HR joiner or mover event triggers it and a role profile scopes it. Both are about deciding. This page is about doing: creating the identity, issuing the credential and enrolling multi-factor authentication, deriving the bundle, creating accounts in every downstream system, and reading the entitlements back out of the target systems to check they are the ones that were approved. If you are designing a request form or an approval chain, use those two. If you are building or documenting the provisioning machinery behind them, including contractor identities and the removal half of an internal move, use this one. If the question is access to a dataset rather than to a system, see /templates/data-access-request-process.
How much of user provisioning can actually be automated?
More than most organisations have automated, and never all of it. Systems behind single sign-on can run without a ticket: the directory identity is created from the HR record, the role's bundle is applied, group membership follows. What defeats full coverage is the estate nobody planned for — the payroll system with no API, the lab instrument that keeps its own local user list, the partner extranet where an account is created by replying to an email. Those need a queue with a named owner and a target time, and they need to be listed, because a manual system that is not on the list is provisioned late for a joiner and missed entirely for a leaver. Keep a register of which systems are connected and which are not, revisit it whenever anything is bought, and treat shortening the manual list as the actual programme of work. Automating the grant without automating the read-back is its own trap: connectors fail silently, which is why the verification step reads entitlements from the target system rather than from the ticket.
How do you provision contractors and other non-employees?
The same way as employees, except that nothing upstream tells you they exist. Contractors, agency staff, auditors, partner engineers, interns and machine identities rarely appear in the HR system, so the two attributes that make an identity manageable have to be captured deliberately: a named internal sponsor who is accountable for it, and an expiry date taken from the contract or the engagement rather than left open. Make expiry automatic — the account disables itself on the date, and renewal is an explicit act by the sponsor with a fresh end date. Reassign the sponsorship when a sponsor leaves, because a sponsored identity whose sponsor has gone is exactly the account nobody reviews. Non-employees usually deserve tighter bundles and a shorter recertification interval than staff too, since their work is narrower and their turnover is faster. Most orphaned accounts an access review turns up belong to somebody the organisation never employed.