SCIM User Provisioning

What is SCIM provisioning?

SCIM (System for Cross-domain Identity Management) provisioning syncs user accounts between your Identity Provider (e.g., Okta, Azure AD) and Intellistack Streamline. When you create, update, deactivate, or reactivate a user in your IdP, those changes are reflected in Streamline without manual user management.

Benefits:
- New users appear in Streamline within minutes of IdP assignment and can be added to projects before first login.
- Deactivated users are marked in Streamline so they aren’t assigned to new work.
- Name, email, and role changes in the IdP flow through to Streamline automatically.

Who can use SCIM?

• Requirement: SSO must be set up with Streamline (SAML or OIDC) with a supported IdP.
• Plans: Available on all Streamline plans.
• Configuration: Done in your IdP and in Streamline (via the SSO Setup Suite). You need IdP admin rights. No separate configuration is required in Streamline; once the IdP integration is active, users sync automatically.

From the SCIM Configuration flow, use Identity Provider (IdP) Selection in the left-hand menu (above SCIM Provisioning) to open the IdP selection page. There you can pick your IdP and follow provider-specific setup instructions. Built-in integrations in the SSO Setup Suite include:

• Okta
• Azure Entra ID
• PingOne
• OneLogin
• JumpCloud
• CyberArk
• IdP General – configure SCIM using a generic protocol if your IdP is not listed

When you select a built-in IdP such as Okta, the SSO Setup Suite shows a provider-specific setup flow. For Okta, that flow is Configure SAML SCIM Provisioning: it lists prerequisites (for example, a working SAML integration), notes that SCIM is not supported on OIDC integrations in Okta, and then walks you through steps in the Okta admin dashboard (e.g. Applications > Applications, then selecting your SAML app) with in-app screenshots. The image below is an example of that Okta-guided flow.

Note: If users were provisioned to the Streamline org before SCIM was set up, a manual push from the IdP may be required.

Testing

To test the SCIM setup, change the user’s name in the IdP and confirm the change appears in Streamline. The update can take a few minutes to propagate.

What SCIM does

Automatic provisioning 

Creating a user in the IdP and assigning them to Streamline creates a matching user in Streamline. They show in the user list and can be added to projects before logging in.

Profile sync  

Changes to name and email in the IdP update the user in Streamline. Email updates change the display email but not the login ID used for sign-in.

Role mapping 

IdP groups are mapped to Streamline roles in Streamline SSO settings. When a user’s group membership changes in the IdP, their Streamline role updates. 

Deactivation

Deactivating a user in the IdP marks them as deactivated in Streamline. Deactivated users do not receive event-based notifications from Core Services. 

Reactivation

Reactivating a user in the IdP (e.g., by re-assigning them to the app) restores their active status in Streamline. Streamline keeps the same user record and history. 

Audit

SCIM-driven changes are sent to Streamline and appear in Streamline’s audit trail.

Important limitations

1. Streamline groups are separate from IdP groups
IdP groups are used only for role mapping. They are not copied into Streamline’s group structure. Streamline groups are managed only in Streamline.

2. Deactivated users are not fully locked down
Deactivated users are marked in the user list and do not get Core Services event notifications, but they can still be added to projects. Full enforcement of “disabled” status across all Streamline areas is not yet implemented.

3. Sync delay (~5 minutes)
IdP changes are not instant in Streamline. Streamline’s audit webhooks usually deliver within about 5 minutes. This delay is a platform limitation and cannot be changed.

4. Okta “Suspend” does not sync
In Okta, only Deactivate drives a status change to Streamline. “Suspend” does not trigger SCIM events.

5. One role per user
Streamline supports a single role per user. If a user is in multiple IdP groups that map to different roles, Streamline uses the first role it sees. Configure IdP groups so each user maps to exactly one Streamline role.

6. Okta: use different groups for app access and role mapping
Using the same Okta group for both “who can access the app” and “push groups” for role mapping can cause race conditions. Use a dedicated group (e.g., can_access_streamline) for app assignment and separate groups for role mapping. See Okta’s guidance.

7. Email change does not change login
If a user’s email is updated in the IdP, the email shown in Streamline updates, but the sign-in identity (login ID) stays the same. Users continue to sign in with their original login ID.

8. IdP support
Only Okta is validated end-to-end. Other SCIM 2.0 IdPs should work with Streamline’s SCIM endpoint, but behavior for non-Okta IdPs is not guaranteed in all cases.

Troubleshooting

User not in Streamline after IdP assignment

• Likely cause: Sync delay
• What to do: Wait ~5 minutes. If still missing, contact support to check Streamline audit logs for a UserCreated event.

Role not updating after group change

• Likely cause: Push groups not set up or wrong groups
• What to do: In Okta, confirm push groups are set for the role-mapping groups. Use different groups for app assignment and for role mapping.

User still active after deactivating in IdP

• Likely cause: Okta Suspend used instead of Deactivate
• What to do: Use Deactivate in Okta; Suspend does not send SCIM events.

Wrong or conflicting role

• Likely cause: User in multiple role-mapped groups
• What to do: Put each user in only one group that maps to a Streamline role.

No sync at all

• Likely cause: Webhook or API key issue
• What to do: In Streamline, confirm the audit webhook connector is on and the SCIM API key/PAT matches what’s configured in the IdP.

Email changed but user can’t sign in with new email

• Likely cause: Login ID unchanged
• What to do: Expected. Sign-in uses the original login ID; only the displayed email changes.

Odd behavior with Okta groups

• Likely cause: Same group for app access and push
• What to do: Use one group for app access and different groups for role push. See Okta’s article.

Security and compliance

• SCIM uses Streamline’s SCIM 2.0 endpoint. API keys and tokens are managed in Streamline and your IdP; Streamline does not store SCIM credentials in the application layer.
• User data sent over SCIM uses the same handling and encryption as your existing Streamline SSO integration.
• All SCIM-related changes are recorded in Streamline’s audit trail.