Skip to content
SkillsDB Help Center home
SkillsDB Help Center home

SCIM - Azure Sync: Critical Considerations

For customers who utilize SCIM to synchronize Azure Entra ID users with SkillsDB automatically, there are few considerations based on limitations related to SCIM and our auth platform, Stytch.

Provisioning Mapping

On our SCIM Setup guide, its imperative to make sure that you have followed the Mapping and Attributes section to specify the externalId mapping attribute.

It's okay to do that now even if it was not done earlier before any more users are provisioned.

Email Change

If the email is changed for any user on Entra ID, it will be handled in the following way for Internal and External users:

Internal Users

For Internal users which were primarily created in Entra ID as user accounts, the email change is going to be propagated, handled and reflected in SkillsDB.

External Users

For External users who are invited as guests to Entra ID, the account email with which they were added cannot be updated.

They will be removed from Entra ID and a new email will be added in its stead. And this is exactly what will happen on SkillsDB: we will deactivate the user with the old email and add a new one with the new email.

User Groups

You can provision 2 types of users in SkillsDB using SCIM sync:

  • Admins - Create an Entra ID Group called SkillsdbGlobalAdmins and add the intended users to it.

  • Full Access - Create an Entra ID Group called SkillsdbFullAccess and add the intended users to it.

  • Basic - Any users outside of this group will be treated as the Basic user category.

    • If a user is a manager of another user (and is not an Admin or Full Access user), then they will be promoted to Manager role automatically.

Manager Provisioning

When provisioning is started for the very first time, it is possible that a direct report is provisioned first and their manager comes into the provisioning flow later.

If this happens, we have no way of knowing if the direct report has the manager assigned due to the way SCIM works.

How to resolve this

The simple way to resolve this is to restart the provisioning on the Azure's Enterprise Application.

Provisioning must be restarted after the first ever provisioning cycle completes after SCIM integration and whenever you think there is a discrepancy in the manager assignment for employees.

There are 2 ways to do this:

Option 1: Manually Restart Provisioning

  • On the Azure Portal, select Enterprise Applications > All Applications.

  • Select the intended application

  • Go to Provisioning > Overview

  • Click Restart Provisioning

Option 2: Automating the restart provisioning process

If you would like to restart provisioning on a regular basis:

  • Identify the Enterprise App instance (service principal)

  • Find the provisioning job ID:

    GET /servicePrincipals/{servicePrincipalId}/synchronization/jobs

    The response has the id you’ll use in the restart call.

  • Make the call:

    POST https://graph.microsoft.com/v1.0/servicePrincipals/{servicePrincipalId}/synchronization/jobs/{jobId}/restart
Content-Type: application/json

{
  "criteria": {
    "resetScope": "Full"   // or omit for a simple restart
  }
}

  • Run it on a schedule/trigger of your choice:

    • Azure Logic Apps / Power Automate: Recurrence → HTTP action (POST to Graph).

    • Azure Automation Runbook / GitHub Actions / DevOps pipeline: Use Graph PowerShell or REST.

Manager unassignment

If an assigned manager is removed from a user without an assignment of another manager, then this will not be reflected because Microsoft does not provision null attributes in such cases. Some quotes from Microsoft documentation:

Link

Entra ID currently can't provision null attributes. If an attribute is null on the user object, it will be skipped. If you for example used to provision the Manager via the integration, but now delete the manager information in Entra ID, the Manager value becomes a null attribute. This will then not be included in the next synchronization

Link

Entra ID SCIM synchronization does note send empty/null values for user attributes. If a user attribute was previously populated with data in Axiad Conductor via SCIM, and then that attribute is set to empty/null in Entra ID, then the change will not be sent to Axiad Conductor.

Reassignments to a different manager is going to work just fine.

User Deactivation

A user will be marked as deactivated — not deleted — in SkillsDB when any of the following actions are performed in the identity provider by the client:

  • User removed from a SCIM group — The user is removed from a provisioned group (e.g. SkillsdbGlobalAdmins or SkillsdbFullAccess).

  • User disabled in the IdP — The user's account is disabled (e.g. "Account Enabled" turned off in Entra ID).

  • User removed from SCIM provisioning — The user is unassigned from the SCIM application in the IdP.

Powered by Plain