SCIM Provisioning not sending requests periodically

Question

Hello,

I am integrating my application with Microsoft Entra ID (Azure AD) using SCIM 2.0 for automatic user provisioning.

The configuration was completed successfully and the initial (full) provisioning cycle ran as expected, creating and updating users correctly in our SCIM API.

However, after the initial sync, more than 24 hours have passed without any new SCIM requests (GET /Users, POST, PATCH, etc.) being sent from Entra ID to our application. Provisioning is still enabled (Provisioning = On) and no errors are visible in the portal.

My question is about the expected behavior of incremental provisioning cycles:

• Does Entra ID suppress SCIM requests when no user or group changes (deltas) are detected in the directory?

When there are no changes, should the service still issue any periodic requests (for example, GET /Users)?

Are there any scenarios where provisioning becomes “silently inactive” without showing errors in the UI?

I would appreciate clarification on how incremental provisioning cycles behave in this situation and whether this behavior is expected.

Thank you.

Answer 1

Hi Elysson,

This behavior is expected for Microsoft Entra ID SCIM provisioning.

After the initial full provisioning cycle completes, Entra ID switches to incremental (delta-based) provisioning. During these incremental cycles, Entra ID only sends SCIM requests when it detects relevant changes in the source directory. If there are no user, group, assignment, or mapped attribute changes, no SCIM requests are sent to the target application.

When there are no changes, Entra ID does not issue periodic or “heartbeat” requests such as GET /Users. Incremental cycles still run internally on a scheduled basis, but if no deltas are found, the cycle completes without generating any outbound SCIM traffic. As a result, it is normal to see no SCIM calls for 24 hours or longer in stable environments.

Provisioning does not become silently inactive. If provisioning is stopped, paused, or blocked (for example, due to repeated failures), this will be reflected in the provisioning status and/or provisioning logs in the portal. When provisioning appears inactive but shows no errors, it typically indicates that there are simply no detected changes to process.

To confirm that incremental provisioning is functioning, you can modify a mapped attribute or assignment for a user or group assigned to the application. Within the next incremental cycle (typically within 20–40 minutes), Entra ID should issue the appropriate SCIM request and record it in the provisioning logs.

Refer:
https://learn.microsoft.com/en-us/entra/architecture/sync-scim
https://learn.microsoft.com/en-us/entra/identity/app-provisioning/scim-graph-scenarios

Answer 2

Nossos fóruns tem suporte nativo em Português, sempre que interagir conosco utilize nosso idioma

Bem vindo à Comunidade Microsoft Azure

Boa tarde. A situação descrita é esperada e, em condições normais, não indica falha no provisionamento.

Após o ciclo inicial (full sync), o Microsoft Entra ID passa a operar exclusivamente por deltas. Isso significa que:

• Nenhuma chamada SCIM é enviada se não houver alterações detectadas no escopo de usuários ou grupos.
• O serviço não executa GET /Users periódicos apenas para verificação.

As requisições SCIM (POST, PATCH, DELETE) só ocorrem quando há eventos reais, como:

• criação ou exclusão de usuário
• alteração de atributos mapeados
• mudança de associação a grupos no escopo
• habilitar ou desabilitar usuário

Portanto, períodos superiores a 24 horas sem tráfego SCIM são completamente normais em ambientes estáveis, portanto o provisionamento não está inativo, apenas não há deltas a processar.