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

• Others

For Admin users, please create an Entra ID Group called SkillsdbGlobalAdmins and add the appropriate users to it.

Any users outside of this group will be treated as the Others user category.

Manager Provisioning

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.

User Deactivation

A user will be marked as de-activated—not deleted—in SkillsDB if any of the following actions is performed:

• A user who was in the SkillsDBAdmins group is now excluded from the group.

• A user who was being provisioned without a group has been de-provisioned.

• A user whose Account Enabled settings has been disabled from the Entra ID platform.