Most identity lifecycle management is two systems that do not know about each other.
The first is your IdP. Okta, Entra, Google Workspace. It handles authentication for everything and provisioning for the apps that support SCIM on the plan you are paying for. That is usually ten to twenty apps, and they work well.
The second is a document. A checklist for onboarding, a spreadsheet for offboarding, a calendar reminder to check last month's leavers. It covers everything the first system does not, which on most stacks is the larger half.
Nobody designed this. It is what you end up with when the tool covers a third of the problem and the rest still has to happen.
Why the second half is the one that hurts
The apps behind SSO are not where accounts get left open. They have the best deprovisioning, the clearest ownership, and the loudest failure mode when something goes wrong.
The damage is in the other set, and it has a specific character.
The doc someone copies from the last hire and edits. It is correct until the org changes and nobody updates it.
One row per app, ticked by hand. It proves somebody ticked a box, not that an account closed.
A recurring reminder to check whether last month's leavers are actually gone. They usually are not.
Access granted through a group that made sense two reorgs ago and now grants more than anybody intended.
Each of those is individually reasonable. Together they are a system with no memory, and that is the actual problem. A checklist records that a step was performed. It does not record why the access existed, so when the person changes teams there is no way to work out which of their fourteen grants should follow them and which should not.
So nothing gets removed. Access accumulates for the length of a career, one quiet promotion at a time, and the first time anyone looks properly is an access review.
One plan per person, recomputed on every change
Iden holds a live record for each identity: what they should have, what they do have, and which system said so.
The should-have comes from policy: department, title, manager, employment type, location. The do-have comes from the connectors, reading each app directly rather than assuming. Where those two disagree, the difference is the work.
That inverts the checklist, which is why it matters. A checklist is a list of actions somebody has to run. A plan is a description of a correct state, and the actions fall out of it. Which lets the plan answer a question a checklist cannot: why does this person have this, and what should happen to it when their role changes.
Nine workflows in three families. The Apps column is the part to read: birthright onboarding touches 32 apps, a regional transfer touches 3.
Workflows are how the plan gets applied, and they come in three families because there are three ways a record changes. Joiner, transfer, leaver. Underneath, each is the same operation: recompute, then apply the difference.
Onboarding, decided before day one
A new hire appears in the HRIS days or weeks before they start. Most processes waste that time, because there is nothing actionable yet and nowhere to put a decision that has not happened.
Iden builds the plan at that moment and holds it. Their manager can see exactly what day one will look like, and change it, right up to the morning it runs. Nothing exists in any app until the start date, so a start date that moves costs nothing to undo.
The same workflow as a definition and as a run. Underneath, three accounts going out for one hire, each with its own ticket ID.
Two things in that screen are worth pointing at.
The workflow is a graph rather than a list, because onboarding has branches a checklist handles badly. Does this person already have a Google account from a previous contract. Is the address taken. Are they suspended rather than absent. A list has to be read by somebody who knows the answers. A graph encodes them once.
And every provisioning task has its own ticket ID. That sounds like plumbing, and it is exactly the point: the app with no SCIM gets an ID like the ones that have it. There is no second class of app living on a different list.
Contractors are the harder case
A contractor is a joiner with an end date, and the end date is the part everybody loses.
Full-time leavers get noticed. Somebody resigns, there is a conversation, HR files it. A contractor engagement just ends, often with no event at all, and their access outlives them by months because nothing was ever scheduled to stop it.
If the end date is in the HRIS, Iden enforces it. If it is not, that is worth fixing before anything else on this page, because it is the most common single source of accounts that outlive the person.
The role change nobody handles
A joiner is visible. A leaver is urgent. A transfer is neither, so the additions get done and the removals do not.
When somebody moves from Sales Ops to Customer Success, a checklist can tell you what Customer Success needs. It cannot tell you which of their existing grants came from Sales Ops and which came from somewhere else, because it never recorded the reason. So the safe move is to add the new and leave the old, and that is what happens almost everywhere.
Iden recomputes and produces a difference. Grants that came from the old department stop being justified and are removed. Grants held for another reason, a project group, an exception somebody made deliberately, survive, because the record knows they were never departmental.
That distinction is the whole value of keeping a plan rather than running a workflow.
Offboarding you can prove
The last day has a clock on it, and it is where the two-system setup shows most clearly. The SSO apps are done in seconds. The rest is a spreadsheet somebody works through, usually while doing their actual job.
Iden runs the whole set in one pass and records how each one closed: deprovisioned over SCIM, closed through the admin console, transferred to an owner. Those are different guarantees, and one green tick for all of them would hide the only thing you are trying to establish.
Order matters here and it is not obvious. Data transfer runs before deletion, because a deleted Google account takes its Drive with it. Sessions are revoked before credentials rotate, because rotating a password does not end a session that is already open. Both are wrong the other way round, and both are the kind of thing a person doing this at 5pm on a Friday gets wrong.
What cannot be decided goes to the app owner with the context attached, and the offboarding stays open until it comes back. A partial exit never gets recorded as a finished one.
What actually changes
The row worth arguing about is the third. Everything else follows from it: if the apps without SCIM stay on a checklist, the checklist stays, and so does everything that comes with it.
What this does not do
It does not replace your IdP. Authentication stays where it is, and the apps Okta or Entra already provision well can keep being provisioned there. Iden reads from your IdP and covers the gap around it.
It does not remove judgement. A shared admin account with no clear owner, a licence expensive enough that reclaiming it is a budget decision, an app where the leaver was the only administrator. These should reach a person, and they do.
And it does not fix an HRIS nobody updates. Every mechanism here is triggered by a record changing. If contractors are not in the system, or leave dates are entered a week late, fix that first. No identity tool will fix it for you.