Employee role changes: A checklist for removing old access

When an employee changes roles, compare the access they hold today with the access their new job requires. For each permission, decide whether to retain it, remove it, add it, or keep it temporarily for handover. Give temporary access an end date and verify the result in the affected app.

This employee role change access checklist is for a transfer within the company. Microsoft's identity-lifecycle documentation calls this the mover phase. The employee remains active, so the plan needs to preserve access they still need while removing permissions that belonged to the old job.

Adding the new role without reviewing the old one can produce privilege creep: access accumulates across successive jobs. Removing everything can interrupt responsibilities the employee still holds. A before-and-after access record makes each decision explicit.

Compare existing grants before deciding what remains, what ends, and what is needed temporarily.

1. Record the move and inventory existing access

Confirm the new role, old and new managers, effective date, and any handover responsibilities. Agree which work must continue during the transition and who can approve an exception.

Consider a hypothetical example: Dana is moving from financial planning to an operations program role. Dana has accounting read access through a finance group, a direct procurement-approver role, edit access to a forecast workspace, a private project channel, and a token used by a reporting integration. Dana also needs to keep ordinary employee access, such as the expense tool.

Inventory the grants in each affected app and record where they come from. Check static groups, dynamic rules, nested groups, direct app roles, resource shares, temporary elevations, and delegated integrations or personal tokens. A group list alone will not describe every path to a resource.

Keep unresolved grants on the list. If nobody can explain a role, assign someone to investigate it before the move rather than silently retaining or removing it.

2. Check which changes automation will handle

A department change can affect access only where a rule or integration uses that attribute. In Microsoft Entra, when a user's attributes change, the system evaluates the directory's dynamic membership rules and adds or removes the user based on whether they now satisfy each rule. Confirm that the expected source attribute changed and that the group result is correct. Also check who can edit the attributes driving dynamic membership; Microsoft recommends auditing those write permissions.

For static groups, identify the workflow or owner that changes membership. For nested groups, check what the downstream integration receives. When a group is assigned to an app, Entra's SCIM provisioning does not expand its nested memberships: a user who belongs to a parent group only through a nested group is not synced as a member of the parent group. The Entra nested-groups guide explains that limitation.

Direct app roles and resource shares need their own review. Do not assume they disappear because a directory group changed.

Write down the boundary of each automated step: which grant it changes, which app receives the change, and which result still needs verification. Avoid treating an automation template as approval to remove every access package or role the employee holds.

3. Approve the before-and-after access record

Have the old manager explain the existing responsibilities, the new manager identify the new requirements, and the app owner confirm what the requested roles permit. The people filling those roles may overlap, but each question still needs an answer.

Assign one decision to each grant:

• Retain: still needed for the employee's continuing responsibilities.
• Remove: no longer needed after the agreed changeover.
• New: required for the new role and approved for addition.
• Temporary: retained for a named handover task until a specific end time.

Do not define the new role by copying another employee's permissions. That account may include old responsibilities and exceptions of its own.

Dana's record might begin like this:

For each row, also record the approver, person making the change, effective time, and completion evidence. Give the temporary row an exact expiry with timezone. Give the integration row an owner who can check whether another process depends on it before changing the credential.

4. Bound handover access and plan the changeover

A handover exception should name the task it supports and the person who approved it. For Dana, forecast-workspace editing might remain available until the replacement has completed a specified handover task, with a fixed deadline for removal.

Use the app's expiration feature where it covers that grant. Otherwise, assign a dated removal task to an owner and a backup. A reminder schedules the work; someone must still remove the access and verify it.

If the handover runs longer, require a new decision and end time. Do not convert a missed deadline into permanent access.

Plan the order of changes so the new role is usable at the agreed start time and the old permissions end when intended. Check documented synchronization and session behavior for the affected apps. A planned transfer generally needs targeted changes. An emergency restriction is a separate procedure with different disruption and timing requirements.

Keep only the old access needed for a defined handover period.

5. Verify old access and new work separately

Check the result at the app, not only the originating group or workflow. A successful directory update shows that one step completed; it does not establish every downstream permission.

Overlapping grants are particularly easy to miss. For example, Notion grants the highest permission level when a user has access through multiple paths, such as a teamspace and a direct page share. Removing the teamspace path may therefore leave access in place through the page share.

For each changed row:

1. Confirm the intended app role or resource grant now exists or has been removed.
2. Check other grant paths that could preserve the old permission.
3. Verify the employee can perform an approved task required by the new role.
4. Verify a removed privilege is no longer available, using the app's effective-permissions view or another approved test.
5. Record the result, time, and verifier.

An existing session or cached permission data may not reflect the change right away. Follow the app's documented refresh or revocation procedure and verify the outcome. Do not infer success from waiting an arbitrary number of minutes.

Use administrative evidence or a supervised check in which the employee controls their own authenticated session. Do not share their credentials or sign in as them to perform the test.

6. Close the temporary grants and unresolved items

Schedule a follow-up for each handover expiry. In Dana's case, confirm that forecast editing was removed and that any reporting integration was retired or transferred through the approved process. The employee should retain only the access still justified by their current responsibilities.

If automation is involved, review its task results as well. Entra workflow history can show which tasks succeeded or failed for an affected user. Assign failed steps to an owner rather than closing the transfer because the workflow ran.

Keep the access record open while a required change or verification remains unresolved. Once complete, retain it as the explanation for the employee's new permissions and the exceptions that ended after the move.