User Provisioning (SCIM): Technical Overview

The platform supports automatic user provisioning from Microsoft Entra ID over SCIM 2.0. Entra ID creates, updates, and removes users in Systam. The customer controls who gets provisioned by assigning users and groups to the Systam enterprise application in Entra.

Protocol

The integration uses SCIM 2.0 (RFC 7643/7644), with endpoints /scim/v2/Users, /scim/v2/Groups, plus the discovery endpoints ServiceProviderConfig, ResourceTypes, and Schemas.

Supported operations: GET, POST, and PATCH on Users, and GET, POST, PATCH, and DELETE on Groups. PUT and DELETE on Users aren't supported — deprovisioning happens with PATCH active=false. Bulk operations aren't supported.

Filtering works with userName eq "value" on Users and displayName eq "value" on Groups. Pagination uses startIndex and count, up to 500 per page.

Authentication uses a per-organization bearer token (Secret Token) generated by the platform. Requests must use Content-Type: application/scim+json. Repeated authentication failures are rate limited.

Entra ID runs the provisioning cycle about every 40 minutes.

Customer-side setup

1. Enable the Microsoft Entra ID extension in the platform's admin view. The platform generates the Tenant URL and the Secret Token, both shown there.
2. In Entra ID, create a non-gallery enterprise application, set Provisioning mode to Automatic, enter the Tenant URL and Secret Token, and run Test connection.
3. Map attributes. Required: userName, name.givenName, name.familyName, emails[type eq "work"].value. Optional: phoneNumbers[type eq "work"].value, preferredLanguage, and the workspace extension attribute urn:ietf:params:scim:schemas:extension:systam:2.0:User:primaryWorkspace.
4. Configure workspace assignment in the platform's admin view (see Workspace assignment below), assign users and/or groups to the application in Entra, and start provisioning.

Synchronized attributes

userName is the link key between the Entra identity and the Systam user.

Work email becomes the user's email and login name. First and last name, work phone (normalized to E.164 using the workspace country, FI by default), additional work or other emails and phones, and preferred language are all stored.

Attributes that aren't stored are ignored without error: displayName, title, department, addresses, externalId, and the enterprise extension (manager, employeeNumber, and so on). Entra's default mappings can stay in place as they are.

User accounts

Provisioned users are regular workspace users without a password. Sign-in goes through SSO or the platform's own login flows. Provisioning doesn't grant admin rights.

On create, an existing user is reused if the same userName is already linked in the organization. Otherwise a new user is created. A match to a user in another organization is rejected (403). A duplicate userName in the same organization is rejected (409).

PATCH updates apply the supported attributes and ignore the rest.

Deprovisioning (active=false) deletes the user account. There's no soft-delete or inactive state, so a user re-assigned later is created as a new account. Organization owners are never deleted, only unlinked from provisioning.

Workspace assignment

Each user is placed in a primary workspace using the first matching rule:

1. Attribute mapping — the primaryWorkspace value sent by Entra is mapped to a workspace in the admin view. Attribute mappings take precedence over group mappings.
2. Group mapping — the Entra group ID is mapped to a workspace. This applies when the user has no primary workspace yet and the group matches exactly one mapping.
3. Default workspace — used when no mapping matches. Single-workspace organizations assign it automatically.

Assignment is sticky: removing a user from a group doesn't remove the workspace, and the primary workspace only changes when Entra sends a new primaryWorkspace value. A sync setting controls whether users are added to the primary workspace only or to every workspace in the organization.

Groups

Groups are provisioned as data only — they don't grant roles or permissions. Their only effect is the group-based workspace assignment described above. Group names should be unique, since Entra matches existing groups by displayName.

Current behavior

• Deprovisioned users are removed rather than deactivated.
• Synchronized attributes aren't configurable per user — Entra always overwrites the synchronized fields.
• Group membership doesn't map to roles or permissions.

That's the technical core of SCIM provisioning. Reach out if a specific customer setup needs more detail.