Why some users during SCIM provisioning getting IsSoftDeleted status true even if the user account was not changed?

Question

The user was successfully provision on demand and user's IsSoftDeleted was false, but the next scheduled provisioning user was deleted from vendor side because IsSoftDeleted was true. During the next provisioning cycle IsSoftDeleted again was false, but user was not provisioned to the vendor side. Now I disable deletion of users and every time the user's IsSoftDeleted is true. We have a few users like this one, and also, we have other users for this SCIM provisioning that do not have this issue. The question is why IsSoftDeleted statos get changed and what needs to be done to avoid this?

Answer 1

Hello Tynuv, Val-A

In SCIM provisioning, IsSoftDeleted=true does not always indicate that the Entra ID account was erased. It indicates that during that provisioning cycle, the provisioning service assessed the user as out of scope or inactive.

This may happen because of:

Modifications to assignments or group membership

• Delays in dynamic group evaluations
• Filters for scoping
• Inconsistencies in attribute mapping
• Temporary modifications to properties such as mapped IDs, accountEnabled, and UPN

Even if IsSoftDeleted later becomes false, some vendors do not automatically reprovision or reactivate the user when the downstream SCIM application receives a delete/deprovision operation.

This seems to be user-specific scope or attribute evaluation behavior rather than a tenant-wide problem because only a small number of users are impacted.

Suggested actions:

• Examine the provisioning logs for the impacted users.
• Verify group/app assignments and scoping filters
• Check mapped attributes for intermittent changes
• Confirm vendor SCIM app supports automatic reprovision/reactivation after delete If deletion should be avoided, leave "Disable deletion of users" enabled.

Usually, the provisioning engine's temporary determination that the user is outside the provisioning scope is the root problem.

Let me know if any further queries - feel free to reach out!

Answer 2

IsSoftDeleted in Microsoft Entra provisioning is a computed status that reflects whether the user is considered “out of scope” or removed for that application, and it is mapped to the SCIM active attribute.

From the SCIM side and Entra provisioning behavior in the provided context:

• IsSoftDeleted ↔ active mapping:
  • In the example schema, status | active | isSoftDeleted (computed value not stored on user) shows that IsSoftDeleted is not a stored directory attribute but a computed value used in provisioning mappings.
  • For SCIM apps, disabling a user is implemented as setting active=false via PATCH.
• Deprovisioning logic:
  • When a user is unassigned from the app, goes out of scope (fails a scoping filter), is soft-deleted in Entra ID, or is permanently deleted, the provisioning service treats the account as deprovisioned.
  • By default, when a user goes out of scope, the service will soft-delete/disable the user in the target app (for SCIM, active=false).
  • If the target app does not support soft-delete, the service sends a DELETE request instead.
• The FAQ for API-driven provisioning reiterates that the SCIM active attribute drives account status: active=true enables, active=false disables.

Given that behavior, IsSoftDeleted toggling to true for some users while others are unaffected typically indicates that, for those specific users, one of the deprovisioning triggers is intermittently true from the provisioning service’s perspective, even if the Entra user object itself was not manually changed:

1. The user may be intermittently out of scope for the provisioning app due to:
   • Group-based assignment changes (user losing/re-gaining membership in the group assigned to the app).
   • Attribute-based scoping filters that sometimes evaluate to false (for example, department, extension attributes, or other filters used in the provisioning configuration).
2. The user may be unassigned and re-assigned to the application between cycles.
3. The target SCIM endpoint may be returning or persisting active=false for that user, and the provisioning mapping is reading that back as IsSoftDeleted=true.

To avoid IsSoftDeleted flipping to true and causing deletes/disable operations:

1. Review assignment and scoping:
   • Confirm that the affected users are consistently in scope for the provisioning app (app assignment, group membership, and any scoping filters).
   • Ensure no automation or process is temporarily removing them from the app or from the in-scope population.
2. Review attribute mappings:
   • Check the mapping where IsSoftDeleted is used and how it is mapped to the SCIM active attribute.
   • Ensure the direction of the mapping is correct (typically Entra → app for active) and that the app is not writing back active=false in a way that is interpreted as IsSoftDeleted=true.
3. Review deprovisioning configuration:
   • By default, out-of-scope users are soft-deleted/disabled. If that is not desired for users who temporarily go out of scope, consider using the “skip out-of-scope deletions” flag so that going out of scope does not trigger a soft-delete or delete.
4. Use provisioning logs:
   • Check the provisioning logs for the affected users to see exactly which event (unassignment, out-of-scope, soft delete, or delete) is causing the service to set active=false / IsSoftDeleted=true and at what time.

Once the root cause (scope/assignment change, mapping direction, or SCIM endpoint behavior) is corrected, IsSoftDeleted will remain false for users that are continuously in scope, and the vendor will no longer receive disable/delete operations for those accounts.

---

References:

• How Application Provisioning works in Microsoft Entra ID
• Tutorial: Develop and plan provisioning for a SCIM endpoint in Microsoft Entra ID
• Using SCIM and Microsoft Graph together to provision users and enrich your application with the data it needs
• Frequently asked questions about API-driven inbound provisioning