SCIM provisioning to Entra ID

System for Cross-domain Identity Management (SCIM) is an open standard for automating user lifecycle across identity providers and SaaS applications. Microsoft Entra ID supports SCIM both inbound (provisioning into Entra ID from an HR system) and outbound (provisioning from Entra ID into third-party SaaS apps).

SCIM outbound — Entra ID to SaaS apps

This is the more common scenario. Entra ID acts as the source of truth, and changes — user created, attributes updated, user disabled — sync automatically to SaaS apps via SCIM:

User created in Entra ID → user auto-provisioned in Salesforce, ServiceNow, Slack, GitHub, AWS, etc.
Attribute change (job title, department, manager) → propagated to all downstream apps.
User disabled → user deprovisioned in all SCIM-connected apps within minutes.
Group membership change → role assignment updated in the target app.

This is how a mature Entra ID tenant achieves automated joiner-mover-leaver: HR triggers a change in Entra, and the change flows everywhere automatically.

Configuration

In the Entra admin center, find the Enterprise application for the SaaS app and choose Provisioning:

Configure Admin Credentials — the SCIM endpoint URL and bearer token from the SaaS app's setup.
Configure Mappings — how Entra attributes map to SaaS attributes.
Configure Scope — assigned users / groups, or all users.
Start the provisioning job.

Entra evaluates the scope periodically (every 40 minutes by default) and reconciles state. Logs show every action with success / failure detail.

SCIM inbound — HR to Entra ID

The reverse pattern: an HR system (Workday, SAP SuccessFactors, Oracle HCM) pushes employee data to Entra ID via SCIM, creating and updating users automatically. Specific HR connectors exist for major systems; generic SCIM 2.0 inbound provisioning supports any SCIM-compliant HR source.

This pattern means HR is the source of truth for employee data. New hires appear in Entra ID before their first day; departures disable accounts on the right day.

Cross-tenant synchronization

A specialised form of inbound SCIM: Cross-tenant synchronization auto-provisions B2B guest users between Entra ID tenants in a Multi-Tenant Organisation. Configured in the Entra admin center, it keeps guest user objects in sync between tenants in the MTO without manual invitation.

SCIM vs SAML vs OIDC

These are different concerns:

SAML / OIDC is for authentication — when a user signs into an app.
SCIM is for provisioning — when an account is created/updated/deleted in an app.

Most SaaS apps use SAML or OIDC for SSO and SCIM for provisioning, configured independently in the same Entra ID enterprise app.

Operational considerations

Attribute mappings are the most common source of issues — wrong mapping = wrong data downstream. Test thoroughly.
Cycle frequency is fixed at 40 minutes — important changes still take time to propagate. Combined with Conditional Access revocation for urgent disables.
Manual invitations and automated SCIM can conflict — pick one as the source of truth per app.

For tenants growing their SaaS footprint, SCIM is the difference between "one new SaaS app, one new manual provisioning process" and "everything connects automatically."

Frequently asked questions

What is SCIM provisioning in Entra ID?

Automatic creation, update, and deactivation of user accounts in a SaaS app based on assignments in Entra, using the SCIM standard. Assign a group to the app and users appear in the app; remove them and they are disabled. It replaces manual account admin in the app.

Why are users not provisioning to my SaaS app?

The user is not assigned to the app, the attribute mapping produces an invalid value (a missing required attribute such as email), the app rejected the request (check the provisioning logs), or the provisioning cycle has not yet run — initial cycles can take up to 40 minutes and incremental ones run about every 40 minutes.

Can SCIM provisioning deprovision users when they leave?

Yes — when a user is unassigned, deleted, or soft-deleted in Entra, the provisioning service disables (or deletes, depending on the app) the account in the target app on the next cycle. Combined with Lifecycle Workflows or HR-driven provisioning, this is how leavers lose SaaS access automatically.