Scenario
You want to provision and deprovision PlusPlus users in real time from your identity provider (e.g., Okta, OneLogin, Azure AD) using the System for Cross-domain Identity Management (SCIM) standard.
SCIM is the recommended people integration method when your IdP is the source of truth for user identity, and is best paired with SSO Integration for a complete sign-in and provisioning experience.
Solution
Setting up SCIM is a two-side process: configure PlusPlus to accept SCIM requests, then configure your IdP to send them.
Enable SCIM in PlusPlus
Sign in to PlusPlus as a platform admin.
Go to System Settings > Integrations > Data Sources > SCIM. [NEEDS VERIFICATION: confirm SCIM lives under Data Sources alongside Workday.]
Toggle Enable SCIM on.
Optionally, configure attribute mappings (see Map attributes below). Default mappings work for most SCIM-compliant providers.
Save your settings.
Note the two pieces of information your IdP will need:
Base URL — your PlusPlus URL plus the path /hooks/scim/v2/. For example: https://acme.plusplus.app/hooks/scim/v2/
SCIM Token — the API token shown on the settings page
Keep the SCIM Token private. It allows the holder to create, read, update, and delete users on your PlusPlus instance.
Configure your identity provider
The exact steps depend on your IdP. The general flow:
Sign in to your IdP as an administrator.
Add or configure a SCIM application targeting PlusPlus. For Okta, see Okta's SCIM provisioning guide.
Use the Base URL and SCIM Token from the previous step to authenticate the connection.
Choose Header Authentication with Bearer as the token type.
Some platforms (including Okta) require the literal word Bearer in front of the token. For example: Bearer d734340c-...-1375d5e83110. Other platforms add the prefix automatically.
Map your IdP's user attributes to the PlusPlus SCIM attributes (name, email, title, department, etc.).
Enable provisioning, push deactivation, and any other actions your IdP supports.
Map attributes
PlusPlus accepts the SCIM core schema, which most IdPs follow by default. You can also remap any standard attribute or add custom attributes from the SCIM settings page.
For an overview of how attribute mapping works in PlusPlus, JMESPath syntax, and how to test mappings against a sample payload, see People Integration: Attribute Mapping.
The SCIM-specific mapping fields are listed in Connection settings reference below.
Validate the integration
Because SCIM is push-based and on-demand, the PI Sync Logs Dashboard does not support dry-run validation for SCIM integrations. To validate a SCIM configuration:
Push a test user change from your IdP — create a user, update an existing user's attributes, or deactivate a user.
Open the user's profile in PlusPlus.
From the kebab menu (⋮) in the top right, select View Custom Attributes to confirm the user's standard and custom attributes were extracted correctly. Use View Last Payload to see the raw SCIM payload your IdP sent.
Go deeper
How SCIM updates interact with other integration methods
SCIM provides three actions:
User creation. When a new user is provisioned in your IdP, PlusPlus creates a corresponding user.
User updates. When an existing user's attributes change in your IdP, PlusPlus updates the corresponding user.
Push deactivation. When a user is deactivated in your IdP, PlusPlus starts the deprovisioning process for the corresponding user.
Important — when SCIM is paired with another integration method: if Workday, a Custom Integration, or CSV over SFTP is also enabled, SCIM user updates are ignored after initial creation. The other integration method becomes the source of truth for user attributes (name, email, title, department, etc.).
SCIM still handles user creation and push deactivation in this configuration. This pattern is intentional — it lets organizations use SCIM for fast provisioning at hire and deprovisioning at termination, while relying on a richer HRIS for ongoing attribute updates.
Restricted-role assignment
The Restricted-role indicator field allows SCIM to automatically assign the restricted role to users who match a path expression — for example, contractors, vendors, or interns. On every SCIM sync, users matching the expression are flipped to restricted; users not matching are flipped to regular. Users with admin or organizer roles are not affected.
Restricted users have a constrained experience: they can only see content explicitly granted to them, and they cannot create content or self-assign content they weren't already granted access to.
For a full explanation of restricted users — what they can and cannot do, when to use the role, and all the ways it can be assigned — see User Roles: Restricted Users.
Connection settings reference
These are the configuration fields available under System Settings > Integrations > Data Sources > SCIM.
Authentication
Setting | Description |
Enable SCIM | Master toggle for the SCIM integration. |
SCIM Token | API token your IdP uses to authenticate. Treat as a secret. |
Standard attribute mappings
All path expressions follow JMESPath syntax — see People Integration: Attribute Mapping for details.
Field | Required? | Description |
Name field | Yes | Path to the user's full name. Example: join(' ', [name.givenName, name.familyName]) or displayName or name.formatted. |
Email field | Yes | Path to the user's primary email. Example: emails[?primary].value | [0] or userName. |
Title field | No | Path to the user's business title. |
Department field | No | Path to the user's department. Example: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User".department. |
Location field | No | Path to the user's physical work or office location. Example: addresses[?primary].formatted. |
Manager field | No | Path to the user's manager identifier. Example: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User".manager.value. |
Manager field (type) | Conditional | How the manager identifier resolves: System ID, Email, or Employee ID. Required when Manager field is set. |
Employee ID field | No (Conditional) | Path to the user's employee ID. Required when used as a primary key. |
SCIM secondary user key | No | Fallback matching attribute used when the primary identifier fails — useful when users change emails in your IdP. |
Employee working-since date field | No | Path to the user's hire/start date. Supports the formats YYYY-MM-DDTHH:mm:ss.SZZ, YYYY-MM-DDTHH:mm:ssZZ, YYYY-MM-DD HH:mm:ssZZ, and YYYY-MM-DD. For other formats, use to_iso_datetime({input}, {format}). |
Person's is-active status field | Yes | Path to a boolean indicating whether the user is active. A false value triggers immediate access removal and starts the configured deprovisioning delay. Example: active. |
Restricted-role indicator field | No | Path expression that resolves to a truthy value when the user should be assigned the restricted role. See Restricted-role assignment above. |
Custom field mappings
Custom attribute mappings are entered as YAML-formatted key-value pairs in the Custom field mappings section. For format and examples, see People Integration: Attribute Mapping.
Date format helper
For hire dates and other date fields where your IdP sends a non-ISO format, the to_iso_datetime() function lets you parse the value explicitly. For example, if your payload contains "hire_date": "6/13/2022 7:0:0 AM GMT", the path expression would be:
to_iso_datetime(hire_date, "M/D/YYYY h:m:s A ZZZ")
For the full list of supported format tokens, see the supported tokens reference.