How to handle a role change

A role change leaves more standing access behind than a departure does, and it is the lifecycle event teams automate last. Both of those follow from the same fact: when a role change goes wrong, nothing breaks.

Joiners get automated first, because the pain is loud and somebody complains on day one. Leavers get automated second, because an auditor asks. Nobody complains about a mover and no auditor has a sample for them.

Why the mover is the hardest of the three

The other two events are one-directional. A joiner needs access added. A leaver needs it all taken away. Both have a date that everyone agrees on and a person whose job it is to care about that date.

A role change is additive and subtractive at once, and it has no clean trigger.

The HRIS records a title change eventually, sometimes weeks after the work actually changed. The person is still at the company, still working, still needs to be productive tomorrow morning. And they usually spend a few weeks handing the old job over. That's a real reason to keep access they're no longer entitled to.

That legitimate reason is the problem. It's the only lifecycle event where the right answer on day one is keep both. Once you've said that, nobody comes back to say when it stops.

When offboarding misses an account, the account sits there until an audit finds it. Someone eventually gets embarrassed. The failure has a shape.

When a role change misses an account, there's no failure at all. The person keeps working. They keep the systems they should have and quietly keep the ones they shouldn't. No ticket, no alert, no finding. Then a review lands 8 months later and someone asks why a sales engineer can write to the billing service.

Consider a support engineer who becomes a solutions architect and then moves into sales engineering. 3 roles over 4 years, one person, and access from all 3 still attached. Nobody removed anything because removing things is work and nothing was on fire.

This is why tenure predicts over-provisioning better than seniority does. The most over-permissioned account in most companies belongs to someone who has been there 6 years and moved twice, not to an executive.

Underneath all of that sit three specific problems.

1. There's no trigger. Title, department, manager, cost centre and location all change at different times, and none is authoritative alone. Most teams end up waiting for a ticket, which means waiting for someone to remember.
2. The overlap is real. Remove the old access on day one and you break a handover that's genuinely in progress. So the default becomes "leave it for now," and "for now" has no end.
3. Nobody owns the removal. The new manager grants the new access, enthusiastically. The old manager has moved on. Nobody's job is to say what should come off.

What a working role change looks like

The mechanism is a diff, computed the moment the record changes, with the revoke half scheduled rather than skipped.

  ROLE CHANGE                support-eng  ->  solutions-architect

  old birthright             new birthright
  ┌──────────────────┐       ┌──────────────────┐
  │ zendesk: agent   │       │ zendesk: viewer  │
  │ jira: support    │       │ jira: eng        │
  │ statuspage: edit │       │ github: read     │
  │ runbook: read    │       │ runbook: read    │
  └──────────────────┘       └──────────────────┘

           diff
           ├── GRANT    jira:eng, github:read        immediate
           ├── KEEP     runbook:read                 no change
           └── REVOKE   zendesk:agent, statuspage    scheduled, day 14
                        (zendesk downgraded to viewer, not removed)

Three things are doing the work here.

The grant happens immediately, because productivity is the thing everyone can see and a slow grant is what gets the whole system turned off.

The revoke is scheduled, not skipped. It gets a date at the moment the role changes, which is the only moment anybody is paying attention.

The extension is a request, not a default. If the handover needs 3 more weeks in the billing system, someone asks for them. The old manager approves. It expires again. An overlap with an owner and an expiry is a handover. An overlap with neither is permanent access wearing a handover costume.

What breaks it

1. Modelling roles as group membership only. Groups move someone from one bucket to another, which handles the coarse layer. It misses everything granted directly: the repository they were added to by name, the dashboard shared with them, the vendor portal account someone made by hand. That layer is most of what accumulates.
2. Approving the grant but not the retain. Every system asks a manager to approve new access. Almost none ask anyone to approve keeping old access. Flip that and the drift stops, because someone has to defend the overlap out loud.
3. Asking the new manager. They'll approve anything, because they have no idea what the old role granted. The old manager is the only person who knows.
4. Waiting for the HRIS title field. Use whatever moves first, usually the manager or the cost centre, and treat the title as the record rather than the alarm.

Doing this without a tool

The manual version is real work but it isn't complicated, and it's worth knowing the shape before deciding it's worth paying for.

1. Write down the birthright set per role. Not per person. If you can't say what a solutions architect should have, you can't diff anything, and this step is the one most teams skip straight past.
2. Trigger on manager or cost centre changes, not titles. Put that report on a daily job into a channel IT reads.
3. Diff by hand. Old role's set, new role's set, and the three buckets: grant, keep, revoke.
4. Grant immediately. Put the revokes in a calendar entry dated 2 weeks out, assigned to a named person, with the list in the body.
5. Make extensions a written request to the old manager, with a new date. An extension with no new date is not an extension.
6. Once a quarter, diff everyone against the birthright of the role they hold today.

About an hour per move, most of it computing the diff by hand.

The quarterly sweep is what stops drift, and it's the part nobody's job description contains. That's the real reason movers compound for years while offboarding gets fixed: offboarding has an owner and a date. This has neither.

What still needs a person

The length of the overlap window. 2 weeks is a reasonable default. It's wrong often enough that a human should be able to set it per move. A migration handover isn't a support rota handover.

Shared and admin credentials, which usually can't be diffed because they were never modelled per person. Those need a decision, and the decision is usually to rotate.

Where Iden fits

Iden computes the diff from the HRIS record and runs both halves. The grant lands immediately. The revoke lands on a date. The extension is a request with an owner and an expiry, not a silence.

Transfers are their own workflow family, separate from onboarding and offboarding, because the shape of the work is different: a transfer touches fewer apps than an onboarding but has to do two opposite things to them.

Nine workflows in three families. The Apps column is the part to read: birthright onboarding touches 32 apps, a regional transfer touches 3.

The part that matters for role changes specifically is grain. A diff between two group memberships isn't much of a diff. Iden governs at repository, channel, project and record level. That's where accumulated access actually lives. The apps that never spoke SCIM get covered by a custom automation framework, not by someone's checklist.

You can also run the diff backwards on people who have already moved. Compare what everyone holds now against the birthright of the role they hold today. That report is uncomfortable the first time. It's also the fastest way to see what a few years of unmanaged movers has cost.