Running joiners, movers and leavers through one process without over-granting access
Onboarding is usually judged by whether the laptop arrives on day one, but the part that lasts is the access. Grants accumulate — a mover keeps what the old role gave them, a leaver's account stays live in the one system nobody owned — and an access review months later is where it surfaces. Run as one orchestrated process, joiners, movers and leavers follow the same spine: the entitlement set is derived from the role, the difference against what the person already holds is computed per system, and anything outside the standard profile reaches the owner of that system before it is granted. Removals run on the date HR recorded, whether or not an approval is still open.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
A lifecycle event is recorded in the HR system — a hire confirmed with a start date, a role or department change with a date, or a leaving date set.
Why it is orchestrated rather than scripted
- Provisioning waits on system owners who are not all in the same team or the same time zone, and the process has to stay open until each one answers rather than granting by default.
- Joiners, movers and leavers are the same shape of work with different removals, so they belong in one process with one editable rule rather than three scripts that drift apart.
- A leaver's access has to be removed on a date known in advance, which means the process must be able to sleep until that date arrives and then act on its own.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Lifecycle event recordedSystem
A hire, a role or department change, or a leaving date is committed in the HR system and published as one event.
- 02
Build the access profileAgent
Role, department, location and employment type are resolved into the entitlement set the role catalog defines for them, each entitlement carrying the source it came from.
- 03
Compare against current accessAgent
What the person already holds is read back from the directory and each in-scope application, and the difference is expressed as grants, retentions and removals per system.
- 04
Within the standard profile?Maestro
The orchestrator routes on whether every grant sits inside the role's standard profile, on whether any is marked privileged or restricted, and on the segregation-of-duties rules.
- 05
System owner approves accessPerson
Each grant outside the standard profile reaches the owner of that system as its own task, with the role, the entitlement and what the person already holds attached.
- 06
Provision and read backRobot
Accounts and memberships are created, amended or disabled per system under scoped credentials, then each system is read back to confirm it holds exactly what was approved.
- 07
Access set and recordedSystem
The person holds the access their role carries and nothing beyond it, and every grant, refusal and removal is written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Access Profile Agent
Turns a role into the set of entitlements that role is supposed to carry.
Reads
- The HR record: role, department, location and employment type
- The role-to-entitlement catalog
- Joiner, mover and leaver rules for that employment type, indexed for retrieval
Decides on its own
Must escalate when
Access Comparison Agent
Works out the difference between what the person should hold and what they hold now.
Reads
- Accounts and group memberships in the identity directory
- Application-level access read back from each in-scope system
- The target profile for the new role
- Grants that were time-bound or issued as an exception
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Provisioning robot
Creates, amends or disables accounts and group memberships, and raises the equipment and payroll tasks that follow.
Runs in
Read-back robot
Reads each system after the change and reports what it actually holds, so the confirmation is not the request repeated back.
Runs in
Within the standard profile?
Every grant in the computed set belongs to the role's standard profile, none is marked privileged or restricted, and no segregation-of-duties rule is breached.
- Passes
- Provisioned without an approval, with the removals applied in the same run.
- Does not pass
- Each non-standard grant is held for the owner of that system; the rest of the profile provisions anyway rather than waiting behind it.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not grant privileged or administrative access on its own, however routine the role. That grant always reaches the owner of that system as a named decision.
- It does not copy an existing employee's access to a new joiner. Access is derived from the role in the catalog, not from whoever the manager pointed at.
- It does not decide who is hired, what role someone moves into, or when they leave. Those facts come from the HR system and the process treats them as given.
- It does not delete an account it cannot attribute to a person. The unmatched account is reported to the identity team with what was found, and left alone.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The identity directory or an in-scope application is unreachable when the change is due to be applied.
- The instance holds at that system's step and the work stays on the queue for retry. The systems that did respond keep their changes, and the outstanding ones remain listed as open — the run is not closed as complete with a system missing.
- The access comparison agent cannot match an existing account to the person, or cannot establish who owns an entitlement.
- That entitlement is taken out of the automated change set and raised as its own task to the identity team, with the account, the evidence and the specific thing the agent could not resolve. The rest of the profile continues.
- A system owner never responds to an access approval task.
- The grant stays unapproved and unprovisioned. The task is re-notified on the schedule the policy sets, then reassigned to the named deputy for that system. The joiner starts without that one system rather than with it, and the instance stays open until the task is answered.
- A leaving date passes while an approval is still outstanding.
- Removal is not gated on the open approval. The scheduled removals run on the date HR recorded, the outstanding task is closed as void, and the change is noted against the instance.
Data, rollout, and what to watch
Data it touches
- The process reads employment data — name, role, department, location, start and end dates — and access data. It does not need salary, bank details or performance records, and those fields are not pulled into the instance even where the HR connector exposes them.
- Agents see entitlement names and the roles they attach to. They never see credentials or secrets: the robot draws those from the Orchestrator credential store at the moment it acts, and they are not written into the process state or the audit record.
- Where residency is required, the process, the directory and application extracts the agents work from, and the audit record all run in the region the organization specifies — including the read-back evidence, since that is what an access review conducted in that region will be asked to produce.
- Retention is set per record type. Access decisions and their approvals are kept for as long as the access review cycle needs to refer back to them; the intermediate directory extracts the agents worked from are discarded when the instance closes.
How it goes live
- 01
Shadow
The process runs beside the existing provisioning route on real joiners, movers and leavers, and computes the access set without writing to any system. Each computed set is compared against what the identity team actually provisioned. The gate to the next phase is that the differences have been explained — either the catalog was wrong and has been corrected, or the manual grant was an exception nobody had recorded.
- 02
Supervised
The process provisions, but every change set is confirmed by the identity team in Action Center before the robot acts, including sets that sit entirely inside the standard profile. The gate is a run of confirmations going through without amendment, and the exceptions that did arise having reached the owner the design says they should.
- 03
Unattended with exceptions
Standard-profile grants and all scheduled removals run without a person. Non-standard grants keep reaching their system owner permanently — that step is a control, not a training wheel that comes off at the end. New applications join the scope one at a time, and each one starts again at shadow.
Signals worth watching
- The share of instances that reach a person, and whether it is drifting. A rise usually means the role catalog has fallen behind how the organization is actually structured, rather than that the agent has got worse.
- How long an access approval sits with a system owner before it is answered, and which systems account for most of that waiting.
- How often a grant approved as an exception is removed again at the next access review — the signal that the standard profile for that role is wrong.
- The gap between a recorded leaving date and the last access actually removed, broken down by system.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- HR information system
- Identity and access management directory
- Payroll
- Service desk and asset register
- In-scope business applications
What the run leaves behind
- The lifecycle event as it arrived from HR, and the role it resolved to
- The entitlement set computed for that role, and where each entitlement came from
- What the person held in each system before the change, and what they held after
- Every grant approved, time-bound or refused, by which system owner, with their reason and the time
- What the robot changed in each system, and the read-back that confirmed it
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.