Loading

SCIM Provisioning

Automatic joiners, movers and leavers from your directory, so an account here follows what your directory says.

SCIM is the standard for automatic user provisioning. It lets an enterprise identity provider create, update, deactivate and delete users and groups in the platform, driven by that organisation's own directory.

Where to find it

Architect Panel → Integration & Connections:

  • SCIM User Provisioning — the endpoint, its token and the mapping

Architect Panel → Security:

  • Permissions — what provisioned groups grant
  • Blocked User Accounts — accounts a directory has deactivated

Provisioning versus sign-in

These are two halves of the same enterprise story and are frequently confused.

  • Single sign-on answers "can this person get in", at the moment they try.
  • SCIM provisioning answers "does this person have an account at all", continuously.

SSO alone means accounts still have to be created and — far more importantly — removed by hand. SCIM is what makes a leaver actually lose access on their last day rather than whenever somebody remembers.

Supported providers

The implementation follows SCIM 2.0, so any conforming provider works. In practice that means Microsoft Entra ID, Okta, OneLogin, JumpCloud, Google Workspace and Ping.

Setting it up

  1. Enable the SCIM endpoint and generate a token.
  2. Configure the connection in your identity provider using the endpoint URL and token.
  3. Map the attributes you need — at minimum a unique identifier, name and email.
  4. Decide what group membership means. Groups arriving from the directory are most useful when they map onto security groups that grant something.
  5. Test with a single user: create, update, deactivate, and confirm each is reflected.

Deactivation is the point

Creation is convenient. Deactivation is the control.

An organisation with SSO but no provisioning has accounts for every leaver — dormant, still permissioned, and still counted in any access review. Test deactivation specifically, because it is the behaviour that matters most and the one people forget to check.

Decide what delete means

SCIM can delete as well as deactivate. Decide which your directory sends and what you want to happen. Deactivation is almost always the right behaviour for a system holding casework — a deleted user account takes with it the ability to interpret an audit trail that says they did something.

Worked example

A customer runs Entra ID. Joiners appear in the platform within minutes of their directory account being created, in security groups matching their department. Leavers are deactivated automatically at their leave date. The quarterly access review, which previously took a day of comparing spreadsheets, became a check that the two systems agree.

Recommendations

  • Test deactivation first, not creation.
  • Prefer deactivate over delete where audit history matters.
  • Map groups to something meaningful, or provisioning gives you accounts with no rights.
  • Keep one break-glass local administrator outside the directory, in case the connection fails.