Skip to content
SkillsDB Help Center
SkillsDB Help Center

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 de-activated—not deleted—in SkillsDB if any of the following actions is performed:

  • A user who was in the SkillsdbGlobalAdmins or SkillsdbFullAccess group is now excluded from the group.

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

  • Pending:

    • Due to a change in our auth provider Stytch's approach from their original one, removal of a user (who is not in a group) is not causing the user to get deactivated for the time being as it did before.

    • We are in touch with Stytch to get this functionality back to its original intent where the user would be deactivated upon removal from SCIM provisioning.

Powered by Plain