Attribute mapping for users and groups

IdP properties are mapped to the SCIM provisioning by attribute mappings. The objectId/externalID is unique in the IdP domain and the UserId is unique in the Synkzone domain. Note that different configurations of the Synkzone SCIM service can create a UserId differently depending on the setup, i.e. if UPN is not configured to be used as the username.

The attribute mapping below is an example that includes the names of the Microsoft Entra ID attributes. If you're using another IdP, use the corresponding attribute from your IdP provider.

User attribute mapping

SCIM attribute	What the IdP should send	Example (Entra ID)	Matching priority	Synkzone field
externalId	A unique, permanent identifier for the user in the IdP. It should never change.	objectId	1	externalUserName
userName	The user's sign-in name, usually in email format.	userPrincipalName	2	userId (derived from the username)
emails[type eq "work"].value	The user's work email address.	mail	n/a	Email
displayName	The user's full name as it should be shown.	displayName	n/a	realName
active	true for an active user, false for a deactivated one.	Not([IsSoftDeleted])	n/a	active
preferredLanguage	The user's preferred language as a language code (e.g. en, sv).	preferredLanguage	n/a	preferredLanguageCode

Use “Direct” as mapping type on all attributes except isSoftDeleted.

Note:

• Matching priority determines how the IdP decides whether a user already exists in Synkzone before creating a new one. It tries priority 1 first, then priority 2. Not every IdP has this setting; if yours doesn't, make sure externalId or userName is used as the unique key.
• userName is used to create the user ID in Synkzone, so it should be stable and unique.
• active: Some IdPs send active directly. Entra ID stores the inverse (isSoftDeleted), so it needs an expression that flips the value: Switch([IsSoftDeleted], , "False", "True", "True", "False").
• Attributes are set at creation only. Changes in the IdP to these fields are not synchronized.
• Language codes: en and sv are avaliable for users in Synkzone
• If externalId or userName matches an existing user

Group attribute mapping

SCIM attribute	What the IdP should send	Example (Entra ID)	Matching priority	Synzkone field
externalId	A unique, permanent identifier for the group in the IdP. It should never change.	objectId	1	externalId
displayName	The group's name as it should appear in the application.	displayName	n/a	name
members	The list of users that belong to the group, each referenced by their SCIM user ID.	members	n/a	members

Use “Direct” as mapping type on all attributes.

Note:

• Matching priority works the same way as for users: the IdP uses externalId to check whether the group already exists in Synkzone before creating a new one. If your IdP has no matching setting, make sure externalId is used as the unique key.
• If a member of a group doesn't already exist in Synkzone, a Synkzone user will be created automatically.
• Group changes are supported. Unlike users, groups can be renamed and have members added or removed after creation through PATCH requests.
• Nested groups: group(s) as member of another group is supported in Synkzone, but many IdPs do not send nested membership through SCIM.