Skip to content

SCIM provisioning

Plugboard implements SCIM 2.0 (RFC 7643 and 7644) so your identity provider can create, update and deactivate technician accounts automatically.

Creating accounts automatically is convenient. Deprovisioning is the reason this feature exists.

Without it, a leaver keeps working access until somebody remembers to deactivate them by hand, and even then their refresh tokens stay valid for up to thirty days. With it, Entra or Google pushes the change the moment HR disables the account, and every refresh token is revoked in the same transaction. Access ends immediately.

An auditor asks about this under SOC 2 CC6.2 and CC6.3, or ISO 27001 A.5.16 and A.5.18. They want to know whether the system enforces it or whether you merely have a process.

You need the SCIM base URL and a bearer token from Plugboard, then you paste both into your identity provider.

  1. Entra admin centre, Enterprise applications, and open (or create) the application you use for Plugboard.
  2. Provisioning, Get started, and set the mode to Automatic.
  3. Under Admin Credentials:
    • Tenant URL: the SCIM base URL from Plugboard.
    • Secret Token: the bearer token from Plugboard.
  4. Test Connection, then Save.
  5. Under Mappings, keep the default user mapping. The attributes Plugboard reads are below.
  6. Set the scope to the group of staff who should have accounts, then turn provisioning On.

Entra syncs on its own schedule, roughly every forty minutes. Use Provision on demand to test a single user immediately rather than waiting.

  1. Google Admin console, Apps, Web and mobile apps.
  2. Open your Plugboard SAML or OIDC application, then Auto-provisioning.
  3. Enter the SCIM endpoint and token.
  4. Map the attributes, then turn it on for the organisational unit that should have accounts.

Any SCIM 2.0 client works. The endpoints are the standard ones under the SCIM base URL, authenticated with the bearer token.

SCIM attributeBecomes
userNameThe sign-in identifier
name.givenName, name.familyNameThe display name
displayNameThe display name, if the parts are absent
emails[primary].valueThe email address
activeWhether the account can sign in
externalIdKept, so the provider’s own identifier links the records

PATCH operations are supported, which is how most providers signal a deactivation: a patch setting active to false.

Provider doesPlugboard does
Creates a userCreates an account. Roles are not assigned; see below
Updates a userUpdates the name and email
Sets active falseDeactivates the account and revokes every refresh token in the same transaction
Sets active trueReactivates the account
Deletes a userDeactivates rather than deleting, so history keeps its attribution

SCIM creates the account. It does not decide what the account can do.

Permissions in a service desk are a judgement about trust, and mapping them from a directory group means a change in the directory silently changes what somebody can wipe. Assign roles in Plugboard.

The practical consequence: a newly provisioned account can sign in and see very little until you give it a role. That is the safe failure mode.

They solve different halves.

  • SSO authenticates: is this the right person.
  • SCIM provisions: should this person have an account at all, right now.

Running SSO without SCIM is common and workable, provided somebody actually deactivates leavers. Running both is what makes the leaver problem stop being a process.

One test, once:

  1. Provision a test user from your identity provider.
  2. Confirm the account appears under Admin, Users.
  3. Give it a role and sign in as it.
  4. Disable the user at the identity provider.
  5. Confirm the account shows as inactive within your provider’s sync window, and that the session is dead rather than continuing until expiry.

Step five is the one that matters. It is also the one nobody tests until an auditor asks.

SCIM is part of the Advanced tier and above. See plans.