SCIM provisioning

The platform supports SCIM 2.0 for automation of user life cycle changes. SCIM provisioning manages user records and organization access. SAML SSO handles authentication. New people usually receive the Employee membership role — set a different role in PeopleFor sign-in attributes-driven roles without SCIM to manage the profile, use SAML Role Attribute.

Synchronization modes

Both end at the same SCIM user resource; they differ in who initiates the change.

Aspect	Native	SCIM Bridge
When it is used	Provider has solid SCIM push support	The provider does not accept SCIM or accepts it poorly
Direction	Push – the identity provider appeals to the platform	Pull – the platform reads the director
Timing	Near real time on assignment changes	Periodic reconciliation on a schedule
Typical providers	Okta	Google Workspace, Microsoft 365 / Entra ID
Who is synced	Anyone you assign to the platform application in IdP	Directory users, minus Bridge exclusion (for example, service accounts or shared mailboxes)

Native

This is the standard IdP → app model when the provider can reliably push SCIM: when someone is assigned to the platform application (or removed), the provider sends the SCIM creating, updating or disabling requests to the endpoint of the platform. Okta This is the native path.

For Microsoft Entra ID, prefer SCIM Bridge Push native – both paths are documented on that page.

sequenceDiagram
  participant IdP as Identity provider
  participant SCIM as Probo SCIM endpoint
  participant People as Organization people

  Note over IdP: Assignment changes
  IdP->>+SCIM: SCIM create / update / deactivate
  SCIM->>People: Apply change
  SCIM-->>-IdP: Result
  Note over IdP,People: The provider pushes each change as it happens

The identity provider pushes every SCIM operation onto the platform as assignments change.

SCIM Bridge

The bridge covers suppliers that don’t support SCIM or support it poorly – including Microsoft Entra IDInstead of waiting for IdP to push, the platform connects to a supported directory, reads users in a program, and reconciles them with people in the organization through the same SCIM path.

sequenceDiagram
  participant Dir as Directory
  participant Bridge as Probo Bridge
  participant SCIM as Probo SCIM endpoint
  participant People as Organization people

  Note over Bridge: Runs on a schedule
  Bridge->>+Dir: Read users
  Dir-->>-Bridge: Directory snapshot
  Bridge->>Bridge: Drop excluded identities
  Bridge->>Bridge: Diff against current people
  Bridge->>+SCIM: SCIM create / update / deactivate
  SCIM->>People: Apply changes
  SCIM-->>-Bridge: Result
  Note over Bridge,People: Probo pulls and reconciles each cycle

Each Bridge cycle reads the directory, applies exclusions, broadcasts against platform users and writes create, update or disable through SCIM.

Running overlapping push and pull automation without a clear owner can cause repeated or conflicting changes.

Endpoint and credentials

SCIM requests use the /api/connect/v1/scim/2.0 endpoint and a carrier token created for a SCIM configuration. The user resource supports the standard creation, reading, listing, replacement, patch and deletion operations implemented by the implementation.

The token is a provision credential, not an API personal key. Store it in the identity provider’s secret warehouse, do not register it and regenerate it when access changes or disclosure are suspected.

Events and failure handling

SCIM events retain the results of requests for operational review and export. Monitor failed events and bridge status instead of assuming directory changes have been applied. Before removing a large assignment group, confirm how the provider represents disabling and deleting and testing with a limited population.

Provider-specific setup pages for Google Workspace, Microsoft 365, and Okta remain available separately.