At a glance
A transfer often triggers a request for new access. The harder question is what the person should stop being able to do. A mover process needs both sides of that decision.
- Compare old and new responsibilities.
- Give handover access an owner and an end date.
- Check the effective permissions after the change.
Start with the work that changed
In this illustrative case, a planner at the fictional Northbank Components moves into procurement. The new manager requests purchase-order access. The old team still relies on the employee for a short handover, and several planning permissions remain assigned.
The transfer is not a simple replacement of a department label. Establish the effective date, the responsibilities ending and the responsibilities beginning. If the person has two genuine assignments, document both rather than forcing the situation into a single job title.
Review retained access deliberately
Ask the old manager which permissions the previous job required. Ask the new owner which of those still support legitimate work. Check direct permissions and temporary exceptions as well as role membership. A change to one role may leave other access paths untouched.
| Decision | What to record |
|---|---|
| Remove | The obsolete permission and the intended removal time. |
| Retain | The continuing business purpose and accountable owner. |
| Retain temporarily | The handover task, end condition and approving owner. |
Avoid “keep everything for now” as the default. It leaves a future reviewer to reconstruct why the person still holds sensitive permissions. A specific handover arrangement is easier to operate and easier to end.
Check the combined permissions
Old and new permissions can create a conflict even if each was appropriate separately. Someone moving from supplier maintenance to payment processing may temporarily hold both capabilities. Ask the business process owner whether that combination requires a different arrangement.
The IGAX website describes lifecycle workflows, role assignment and a policy and segregation-of-duties engine. Those are relevant capabilities for designing a mover process. The organisation must still define which combinations are unacceptable and how temporary exceptions are approved.
Verify the result in the application
After the change, check that the intended new access exists and that obsolete access has ended. Keep failed removals visible. If a target application was unavailable, a completed HR update should not be reported as a fully completed access change.
Review the end of the handover separately. The end date needs an action and a check, not just a note in the original request. If an extension is necessary, record a new reason and approval.
Microsoft’s lifecycle guidance distinguishes movers from joiners and leavers. Treating movement as its own event helps the design address changed responsibilities rather than only account creation. Microsoft Learn: What are lifecycle workflows?.
References
Primary guidance used for the specific points cited above. The examples, templates and recommended working practices are AIdentX editorial guidance.
Sources reviewed September 2026.
Published by AIdentX Editorial. Illustrative scenarios are fictional and do not represent customer results.