Skip to content

Glossary

SCIMsystem for cross-domain identity management

An open standard for creating and removing accounts in other systems automatically, so joining and leaving are handled once rather than everywhere.

In plain terms

One list of who works here, and everything else keeps itself in step with it. Somebody joins and their accounts appear; somebody leaves and they go. The interesting half is the second one, because creating accounts has an impatient person chasing it and removing them has nobody.

01

Why it matters

Because leaving is the part organisations get wrong, and they get it wrong quietly. A departure produces a list of systems somebody has to remember, and the ones remembered are the ones with a licence cost attached. Accounts that cost nothing to leave open are the ones left open, which over a few years is how an organisation ends up with working logins belonging to people who left it.

02

How it works

One system holds the record of who exists and pushes changes outward. Creating, updating and removing accounts all originate in the same place, so the question of who works here has one answer rather than one per product.

It is a published standard rather than an arrangement per vendor, which is the point. Both halves are defined in public specifications, so a product supporting it works with an identity system that supports it without either having built anything for the other.

Removal is where the value concentrates and where support is thinnest. A vendor gains a customer from provisioning and gains nothing from deprovisioning, so the create path is reliably implemented and the remove path is the one worth asking about specifically.

It is a different thing from single sign-on and the two are constantly confused. Signing in is about proving who somebody is at the moment they arrive; this is about whether an account exists at all. A product can have the first without the second, in which case a departed employee cannot sign in through the front door and their account is still sitting there.

AI tools are frequently outside it, which is the gap worth naming. Assistants and search deployments are often adopted by a team rather than through procurement, so they never enter the arrangement, and they are precisely the tools that reach the most material.

The two directions, and why only one gets built

The two directions, and why only one gets builtThis asymmetry is not a criticism of any particular vendor, it is a description of where the pressure comes from, and it predicts what you will find. Provisioning has an impatient new employee, a manager chasing on their behalf, and a failure that surfaces the same morning; it gets built well and demonstrated readily. Deprovisioning has none of those. The person it concerns has left, nobody is inconvenienced by it not working, and the failure is an account quietly continuing to exist, which produces no signal of any kind until somebody goes looking or something goes wrong. That is why a buyer reading a support claim should treat it as a claim about the first column, and ask about the second explicitly: what happens to the account, what happens to material it holds, and what happens to a session already open. The same asymmetry explains the AI-specific version of the problem. Tools adopted by a team rather than through procurement were never in the arrangement in either direction, so nothing removes anything, and those tools are typically the ones with the broadest reach into company material.JoiningSomebody is waiting and asking.Failure is visible withinhours.A vendor gains a workingcustomer.LeavingNobody is waiting or asking.Failure is invisible for years.A vendor gains nothing at all.Both directions are in thestandard and only one hasanybody pushing for it, which iswhy support for the second isworth confirming separatelyrather than reading off thefirst.
This asymmetry is not a criticism of any particular vendor, it is a description of where the pressure comes from, and it predicts what you will find. Provisioning has an impatient new employee, a manager chasing on their behalf, and a failure that surfaces the same morning; it gets built well and demonstrated readily. Deprovisioning has none of those. The person it concerns has left, nobody is inconvenienced by it not working, and the failure is an account quietly continuing to exist, which produces no signal of any kind until somebody goes looking or something goes wrong. That is why a buyer reading a support claim should treat it as a claim about the first column, and ask about the second explicitly: what happens to the account, what happens to material it holds, and what happens to a session already open. The same asymmetry explains the AI-specific version of the problem. Tools adopted by a team rather than through procurement were never in the arrangement in either direction, so nothing removes anything, and those tools are typically the ones with the broadest reach into company material.
03

Seen in the wild

  • Checking whether an assistant's enterprise plan supports automatic removal, not only automatic creation.

    ChatGPT
  • Confirming a search deployment loses a departed employee's account rather than only their sign-in route.

    Glean
  • Finding a team-adopted tool that never entered the arrangement and holds accounts nobody is tracking.

    Notion AI
04

Common misconceptions

People assume

Single sign-on already handles leavers.

In fact

It handles the sign-in route. The account can still exist, along with anything it holds and any direct password that was set before the route was introduced. Removing the way in is not the same as removing the thing it led to.

People assume

Supporting it means both directions work.

In fact

Creating accounts is where vendors invest, because it is what a new customer notices. Removal is the half that matters for risk and the half worth confirming explicitly, since a product can claim support and implement mostly the first direction.

05

Questions

What should we ask a vendor beyond whether they support it?
Whether removal works and how quickly it takes effect. Provisioning is what gets demonstrated in a sales conversation and deprovisioning is what matters afterwards, so the useful question is what happens to an account, its stored material and any active session when somebody is removed from the source.
Is it worth it for a small organisation?
The benefit scales with how many separate products people hold accounts in rather than with headcount. A small team using a dozen tools has the same forgetting problem as a large one, and the plans that include it are often the more expensive tiers, which is the real constraint.
Why are AI tools so often outside it?
Because they are frequently adopted by a team directly rather than through procurement, so nothing routes them into the arrangement. That is also why they matter here: a search or assistant deployment usually reaches more material than the systems that were set up properly.
06

Key takeaways

  • The value is in removal, which is the half nobody chases.
  • It is a published standard, so support is not a per-vendor negotiation.
  • Single sign-on removes the route in; this removes the account.
  • Team-adopted AI tools are usually outside it entirely.
08

Tools that use this

  • ChatGPT

    Whether the enterprise plan automates removal as well as creation.

  • Glean

    Losing a departed employee's account, not only their sign-in route.

  • Notion AI

    Team-adopted tools that never entered the arrangement at all.

Last checked August 2026

All glossary terms