I'm trying to build a reliable process for moving employees between departments in Microsoft 365. A department change can affect security groups, Teams, SharePoint sites, OneDrive, and mailbox permissions. What's the best way to confirm that the employee's previous access has been removed and the new access works, without manually checking every resource?
5 Answers
The cleanest approach is to assign access through role or department groups rather than directly to individual users. When someone changes roles, remove them from the old group and add them to the new one. Then verify group membership and use scripted checks or test accounts to confirm the expected permissions.
Some organizations handle complicated moves as an account transition: disable or archive the old identity and create a new one with only the new department’s permissions. It gives you a very clean access boundary, but you need a careful plan for mailbox history, OneDrive files, ownership, and business continuity. For most environments, well-designed role groups are less disruptive.
Treat a department change as its own documented workflow, similar to onboarding and offboarding. HR should trigger the change, the old role-based access should be removed, the new access should be assigned, and the final step should be an audit report or automated test showing the effective permissions—not just confirmation that someone completed the checklist.
Use HR’s department or job-role attributes to drive access assignments, then automate validation with PowerShell or Microsoft Graph. The checks should compare the user’s actual group, Team, SharePoint, OneDrive, and mailbox permissions against the access they are supposed to have for the new role.
Make sure the validation also looks for exceptions, such as direct SharePoint permissions, delegated mailbox access, and permissions inherited from nested groups. Those are easy to miss if you only check profile-based assignments.
If someone genuinely needs temporary access to their former department as a backup, make it explicit and time-limited. Put an expiry or review date on that access instead of leaving it permanently in place under a vague ‘just in case’ exception.
That makes sense. A separate temporary-access group with an owner and review date would be easier to audit than leaving the old permissions attached indefinitely.
That works especially well when permissions are consistently tied to groups. Direct permissions and one-off exceptions are what usually make the process difficult.