Turn provisioning logs and quarantine into an identity-delivery work queue

Bottom line: Microsoft Entra’s provisioning service records its read and write operations in provisioning logs and can place a repeatedly failing job into quarantine. A quarantined or partially failing job is an identity-delivery condition: joiners may lack access, movers may keep the wrong access, and leavers may remain enabled downstream.

Source fact: what Microsoft documents

Microsoft’s application provisioning explanation describes initial and incremental cycles that evaluate scope, match source and target objects, and create, update, disable, or delete objects according to mapping and target capabilities. All provisioning-service operations are recorded in the Microsoft Entra provisioning logs, including source and target reads and writes.

Microsoft documents quarantine behavior when errors exceed a threshold or the service encounters certain conditions. In quarantine, the service reduces how often it attempts the job. After the underlying errors are corrected, a subsequent cycle can move the job out of quarantine. Microsoft also documents that a job left in quarantine for an extended period can be disabled. Performance and completion time depend on the provisioning scenario and cycle.

What the source does not establish

A running job is not proof that every in-scope object is correct. A successful provisioning entry does not establish that the user can perform the intended business task, while a skipped entry may be correct or may reveal a scope or mapping defect. Entra logs do not necessarily contain every application-native change. Restoring the job does not repair access that was granted manually or actions that failed outside the connector.

Applicability questions

• Which source attributes, scoping filters, mappings, and matching attributes determine each target object?
• Does the target support disable, delete, group, and role behavior required by the lifecycle policy?
• Who owns connector credentials, target API limits, schema changes, and target-side errors?
• How quickly must joiner access arrive and leaver access disappear?
• Where are alerts sent when the job enters quarantine, slows, or is disabled?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Assign a service owner and application owner to each provisioning job. Define severity from the access consequence, not merely the connector error count.
2. Monitor job health, quarantine state, cycle completion, and representative create, update, disable, and delete outcomes.
3. Route failures into an owned queue with object identifier, action, error, age, business impact, and next step. Protect sensitive log data.
4. After remediation, run or await the supported cycle and verify the target object and application behavior directly.
5. Reconcile target accounts and privileges periodically to find manual, orphaned, unmatched, or out-of-scope access.

Verification and evidence

• Preserve provisioning job configuration, mappings, filters, target credentials metadata, and change approvals.
• Retain relevant provisioning-log entries showing evaluation, source and target action, result, and remediation.
• Test representative joiner, mover, leaver, rehire, duplicate-match, missing-attribute, and target-failure cases.
• Document recovery from quarantine and confirm the backlog cleared without unintended writes.

Official references

• Understand how Application Provisioning in Microsoft Entra ID — Microsoft