---
Title: "Mover lifecycle access: remove old grants, verify new ones"
Url: "https://devrev.ai/blog/employee-role-change-access-mover-ai"
Published: "2026-10-15"
Last Updated: "2026-10-16"
Author: "Nivedita Bharathi"
Category: "Blog, Employee Experience"
Excerpt: "Every role change is a diff of minus and plus lines. Here is who owns each kind, what proves it is done, and who signs for the residual."
Reading Time: 6
---

# Mover lifecycle access: remove old grants, verify new ones

_A role change is a diff with two kinds of lines. Here's who owns each kind, and what proves it's done._

_Illustrative role-change diff, invented for this article._

Every role change produces a diff like this one. The plus lines tend to move fast, because the employee is waiting for them. The minus lines drift, because nobody is waiting for them.

This diff belongs to Taylor Ellis, an invented support engineer moving to the security team. Taylor, the record, and everyone below are fictional, built for this article. It isn't a customer story, a product test, or a default policy.

**Mover lifecycle access** is finished only when both kinds of lines carry evidence. Every minus line needs a named owner and proof that the old right is gone. Every plus line needs an approver and proof that the new right works.

## One record, three owners

A **mover** is an employee who stays at the company but changes role, team, or department, so their access needs change too. The move itself is the trigger. The diff is what follows from it, and different people own different parts.

| Part of the change | What you decide | Taylor's case (fictional) |
| --- | --- | --- |
| Trigger and source | Which HR field changes, and which system is the source of truth | HR operations owner Nina Voss confirms HR-CHG-0417 |
| Remove set | Access tied to the old role | Three lines, owned by Cameron Wells in identity operations |
| Retain set | Access every employee keeps | Email, wiki, HR self-service |
| Add set | Access tied to the new role, with its approver | Two lines, approved by security team lead Ari Lemaire |
| Fulfillment | Who assigns the new access | Ines Moreau on the security tooling team |
| Confirmation event | What proves each change in the target system | Set per line, below |
| Backup owner | Who acts if the primary owner doesn't | Remy Holt, for removal |

HR starts the change, and identity operations carries out the removal. A resource owner approves the additions. Set these fields before any move happens, as decisions rather than prefilled answers.

Two actions are off-limits from the start: leaving the old support admin access in place, and granting security tooling before Ari approves. This is where the request journey from [AI for IT support](https://devrev.ai/blog/ai-for-it-support) meets lifecycle design. For who may request or grant access at all, see [AI agent authorization](https://devrev.ai/blog/ai-agent-authorization).

Keep this stage separate from first-day bundles. Those belong to joiner handling, not to a move.

## The minus lines: removal needs an owner and a denial

Before the move, Taylor holds 3 old entitlements and 0 new ones. The decision is to remove 3, retain 3, and add 2 after approval.

Cameron checks each target system, not only the request tracker. A confirmed removal needs two things. The entitlement is gone from the target system, and a controlled test of the old action is denied.

| Minus line | First check | State |
| --- | --- | --- |
| Refund-approval group | Entitlement absent; test refund approval denied | Removal confirmed |
| Customer data export group | Entitlement absent; test export denied | Removal confirmed |
| Support admin console role | Group removed, but the console still lists an admin role on Taylor's profile | Removal not confirmed |

So the first check shows 2 of 3 removals confirmed. The group was gone, yet the console kept its own role.

For the permissions check behind each step, see [AI access control](https://devrev.ai/blog/ai-access-control). That page covers the check. It doesn't make removal happen, and neither does this example.

Cameron asks the console owner to remove the admin role. Under the team's local policy, Cameron also disables Taylor's console access until the role is gone. Then the console shows no admin role, and a test admin action is denied.

Sessions need their own evidence. Removing someone from a group doesn't establish that their live sessions have ended. Identity-provider documentation, including Microsoft's guidance on revoking user access, explains that an application can keep its own session after an account change.

So Cameron records the target application's session-revocation evidence. Taylor then signs in again and confirms the old action is denied. That fresh sign-in shows the old action is denied in a new session. It doesn't prove older sessions ended, which is why the application's own record matters.

## The plus lines: approved isn't usable

The additions fail differently. They're rarely forgotten. More often, they stop one step short of working.

| Plus line | First check | State |
| --- | --- | --- |
| Security investigation tooling | Ari approved; Ines created the account, but no analyst role is assigned yet | Assignment pending |
| Case-management read access | Ari approved; role assigned, not yet checked | Assignment made, effective access unverified |

That's 0 of 2 grants confirmed. Assigning a role is not the same as effective access, so each plus line needs a target-system entitlement and one permitted action.

Ines assigns the analyst role, and Ari's approval stays on record. Taylor runs one permitted search in the security tooling and one case read. Both succeed. The retained email, wiki, and HR self-service all still work.

This is the completed-work test from [Employee self-service beyond the ticket](https://devrev.ai/blog/employee-self-service-beyond-the-ticket). A closed request is not completed work. A confirmed state is.

## The residual record

Taylor's move ends at 3 of 3 removals confirmed and 2 of 2 grants confirmed, with the 3 retained items intact. These outcomes are authored for the example, not test results. The useful artifact is the record that would have held anything left over.

Here's a proposed shape for it. It isn't an industry standard, and the state names are illustrative, not product fields.

| State | Meaning | Evidence |
| --- | --- | --- |
| change_triggered | The HR record is approved and effective | HR record ID and date |
| remove_set_requested | Removal was requested through an authorized path | Request ID and requester |
| remove_confirmed_in_source_system | The access is gone, and a controlled test of the old action is denied | Entitlement export or log, plus the test result |
| add_set_approved | The named approver said yes | Approver name and time |
| add_confirmed_in_source_system | The new entitlement exists, and a permitted action works | Entitlement export or log, plus the test result |
| residual_open | Something is requested or approved but unconfirmed | Owner and due date |

![Illustrative role-change diff separates removed, retained, and added rights and tests each in the target system; session revocation is a separate check.](https://cdn.sanity.io/images/umrbtih2/production/ed47115cbbf7722ff75169a04a8f8765f8bb89cb-5334x2667.png)

_Illustrative mover check – Old rights need removal and a denied-use test; new rights need approval and a working action. Session revocation needs separate evidence._

You can merge fields for readability. Don't merge "requested," "removal confirmed," and "new grant confirmed" into one status. That merge is how a lingering admin role hides behind a closed ticket.

In mover lifecycle access, residual items stay on the board until both halves are confirmed, with one owner per half. Your team sets the confirmation interval locally. This article doesn't give a number, because the right one depends on your systems and risk.

Had the console role still shown at the deadline, the change would stay open and move to Remy. An access review would then be scheduled. Recovery is a named handover, not a reminder email.

To see whether your process works, design two measures and their denominators first:

- Requested removals compared with confirmed removals, such as across moves in a quarter.
- Access held after the move compared with access the new role needs, reviewed at the point you choose.

These measures show whether your own process holds. They don't prove that any tool caused an improvement.

## Who signs for the old role

With a residual record in hand, you can judge tooling on your terms. For background on how Computer, by DevRev, approaches IT help, [Computer for service desk](https://devrev.ai/blog/computer-for-service-desk) is a reasonable start. Treat it as context, not proof that your configuration supports removal or grant actions. Test any role-change workflow against your own diff.

The questions follow the diff. Can a configuration read an approved role-change record and request each line through an authorized path? Does it route minus lines and plus lines to their owners, and what confirms each one in the target system? [Enterprise AI agent buying criteria](https://devrev.ai/blog/enterprise-ai-agent-buying-criteria) helps you decide what else to require.

In Taylor's move, Cameron accepted the change only after the evidence showed 3 of 3 removals and 2 of 2 working grants. The signature doesn't revoke anything. It records who checked that the old role is gone.

So a move isn't finished when someone can do the new job. It's finished when the old rights are proven gone and someone has signed for that proof.

Who signed for the old role in your last move, and what did they check? If nobody can say, pick that move, write its diff, and [talk through the cutover with DevRev](https://devrev.ai/request-a-demo), minus lines first.