Skip to main content
SCIM keeps your G360 user list automatically synchronized with your identity provider. Without it, an administrator has to add, update, and remove G360 accounts by hand. SCIM is configured after SSO is working. If you haven’t done that yet, start with SSO Setup.

​
Check availability first

SCIM is not available on every provider or plan. On some providers it is unavailable at any price; on others it needs a specific licence tier. Check this before planning a rollout around it.
If your organization runs Microsoft 365, check your licence before assuming SCIM is out of reach. P1 is often already included in Microsoft 365 Business Premium, M365 E3, or EMS E3, even if nobody bought it separately. Office 365 E1–E3 and M365 Business Basic/Standard do not include it. Check the billing or licence pages in your Microsoft 365 admin center, or ask a Global or Billing Administrator about the self-service 30-day P1 trial.

​
What SCIM syncs

With SCIM enabled, your identity provider can push the following changes into G360.

​
Step 1: Generate a token in G360

1

Enable SCIM Provisioning

Go to Settings → SSO Settings, scroll to SCIM Provisioning, and enable it.
2

Name and generate a token

Enter a Label describing where the token will be used — for example Okta provisioning — then click Generate token.
3

Copy the token immediately

Copy the generated bearer token as soon as it appears and store it somewhere safe. The token is shown only once.
G360 SCIM Provisioning settings with a label field, Generate token button, and a table of existing tokens

SCIM Provisioning section — generating a bearer token for the identity provider.

Paste the raw token only — do not type Bearer in front of it. Your identity provider adds that prefix itself. Typing it yourself produces a silent authentication failure that looks identical to having pasted the wrong token. Watch for a trailing space from the copy-paste, too.

​
Step 2: Configure your identity provider

Where you paste the token, and what else needs configuring, is different for every provider.

PingOne

One application handles both SSO and SCIM.

OneLogin

Needs a second SCIM Provisioner application.

Okta

Needs the catalog SCIM 2.0 Test App.

Microsoft Entra ID

Needs a second non-gallery application, and P1/P2.

Other OIDC provider

Any provider that can push SCIM 2.0 to a bearer-token endpoint.
A user must be assigned to every application that SSO and SCIM use — not just one.
  • Assigned to the SSO application but not SCIM → they can sign in normally, but will never be deprovisioned when they leave. This is a silent security gap, not just a setup inconvenience.
  • Assigned to SCIM but not SSO → they’re provisioned but can’t sign in.
Whenever you grant or remove access, check every application involved.
Map the field that becomes SCIM’s userName attribute to the user’s email address. This is the single most common SCIM setup mistake, and it fails silently on every provider — see Users are being created repeatedly below.

​
Token management

Only one SCIM token can be active at a time. Generating a new token immediately revokes the current one, which breaks provisioning until the new token is pasted into your identity provider. The token table shows: Click Revoke to invalidate a token immediately. Do this as soon as you suspect a token has been exposed, or when you decommission an identity provider.

​
Troubleshooting

Possible causes
  • SCIM provisioning is not enabled, or the SCIM token has been revoked.
  • The employee has not been assigned to the G360 application — or, on Okta, OneLogin and Entra ID, to the separate SCIM application.
Resolution
  • Check the Last used column in the token table. If the value is stale, the token may have been revoked by a newer one. Generate a new token and update it in the identity provider.
  • Confirm the employee is assigned to every application that handles provisioning for your provider.
  • Without SCIM, the account is created the first time the employee signs in through SSO (if new-user provisioning is enabled).
Possible causes
  • SCIM provisioning is not enabled or is not running.
  • The user was removed from the directory but never unassigned from the G360 application.
  • The user was only ever assigned to your SSO application, never to the separate SCIM application (Okta, OneLogin, and Entra ID all use two applications).
Resolution
  • Confirm SCIM is enabled and the token is still active.
  • Disable or unassign the user in the identity provider. Their G360 account moves to Suspended and they can no longer sign in.
  • Check the user is assigned to every application that matters for your provider, not just the one used for sign-in.
Identity provider user profile with the enabled toggle switched off and a confirmation that the user can no longer sign on

Disabling a user's sign-on access in the identity provider.

Possible cause — Your identity provider doesn’t support SCIM on your current plan or application type.Resolution — Check the availability table. Google and Amazon Cognito cannot do SCIM under any configuration. Entra ID needs a P1 or P2 licence — Entra ID Free cannot provision at all, even if everything in G360 is configured correctly. Okta needs the specific catalog application, not your regular OIDC integration.
Possible cause — Your identity provider’s userName field for SCIM isn’t mapped to the user’s email address.Resolution — Open your provider’s SCIM attribute mapping and confirm the field mapped to userName is set to email, not a directory username or display name.Why it fails so quietly: the provider searches G360 for a user it doesn’t hold, finds nothing, tries to create them, and is told the email already exists. It repeats that on every sync and never learns G360’s record for that user — so no update and no deprovision ever arrives either.This has to be fixed going forward. Accounts already created with the wrong mapping may need cleaning up manually with your G360 administrator.