| SCIM attribute | Use in Mercura |
|---|---|
userName | The user's e-mail address and Mercura identity (required); see below for directories where it is not an e-mail address |
emails | Used only when userName is empty (primary entry first) |
displayName, name.givenName, name.familyName | Display name (displayName wins) |
externalId | Your directory's identifier for the user, unique per organisation |
active | false blocks sign-in, true restores it |
preferredLanguage | Interface language (e.g. de, en-GB), read only when the user is created; without it the organisation's default applies |
groups | Group memberships sent on the user (Okta style), used for the role |
Other attributes — phone numbers, addresses, title, the enterprise extension — are accepted and ignored.
Match sign-in and userName. Mercura links a Microsoft sign-in to the provisioned user through the e-mail address that Microsoft puts in the sign-in token, which is the user's mail attribute. Entra ID maps userName to the user principal name (UPN) by default. If UPN and mail are the same in your directory, nothing needs to change.
If they differ and userName must stay the UPN, ask Mercura support to take the e-mail address from emails for your organisation. Mercura then uses the primary entry of emails (else the work entry, else the first) as the user's e-mail address, for sign-in and for notifications, and keeps userName exactly as sent, so filters and responses use the UPN. Entra ID sends mail as emails[type eq "work"].value by default; keep that mapping. A user provisioned without emails falls back to userName and cannot sign in with Microsoft until emails arrives. Without that setting, map userName to mail instead.
Existing users. If a user with the same e-mail address already exists in your organisation — for example because they were invited before SCIM was set up — the first create links that user instead of creating a second one. From then on the identity provider manages them, and their role comes from the group mapping below.
Deactivate or delete. active: false blocks sign-in immediately and keeps the user, their requests and their offers; active: true restores access. DELETE removes the user from provisioning and blocks sign-in as well; their data stays in Mercura. Deactivation is fully reversible, so prefer it for temporary removals — re-provisioning a deleted user may need help from Mercura.