Entra ID provisioning on-demand failed: user not matched by scoping fi

Not specified by the original author.

TL;DR

Bring the user into scope deliberately or confirm exclusion is correct. Read the scoping filter on the provisioning job, test the hire attributes against each condition, fix the attribute or filter that wrongly excludes them, such as a department value or user type, then run on-demand provisioning again and confirm the full job will include them on its next cycle too.

Entra ID provisioning on-demand failed: user not matched by scoping filter

Use this when

• Provision on demand reports the user is skipped or not matched by the scoping filter.
• The hire belongs to a department, location, or worker type the filter handles specially.
• Full sync also never creates the account, confirming scope rather than a transient error.

Not for this skill when

• The user is intentionally excluded, for example a service account class. Document the exclusion instead.
• On-demand fails with a target error after matching. That user is in scope; debug the target operation.

Steps

1. Open the Entra provisioning job scoping settings and the on-demand result detail for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. In the app Provisioning settings, open the scoping filter or scope configuration and list every condition, then compare each one with the hire directory attributes exactly as stored, including user type, department, and any extension attributes the filter reads. Verify: each filter condition is marked pass or fail for the hire
3. Fix the failing side: correct the hire attribute in the source if the value is wrong or in an unexpected form, or amend the filter if a legitimate new department, location, or worker type was never added when the business created it. Prefer fixing source data when the filter expresses real policy. Verify: the saved filter or attribute now agrees for the test hire
4. Apply the correction in Microsoft Entra ID and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Confirm no second scope layer still excludes the user, such as the app assignment list or a group-based assignment the provisioning scope depends on, since on-demand respects the combined scope. Verify: the hire downstream assignment check passes in Entra
6. Add the hire population pattern to the scope review that happens when HR creates new departments or worker types, so scope filters gain new values as a planned change. Verify: the review step is documented with the provisioning owner

Why it happens

Scoping filters decide which users a job may touch at all, and on-demand provisioning honours them strictly, so a user outside the filter is skipped before any target call is made. Filters drift from reality as companies add departments, locations, and contingent worker types whose attribute values nobody adds to the filter, and source data typos exclude individuals the same way. Because skipped users produce no target-side errors, the only evidence is the scope result itself. Testing the actual attributes against the actual filter turns an invisible exclusion into a one-line correction.

Variants and edge cases

Filter uses a department that HR renamed

Renames break exact-match filters silently for the whole department. Update the filter in the same change window as the HR rename and re-run a full sync.

Extension attribute empty for HR-fed users

When the filter reads an extension attribute the HR feed never populates, switch the filter to a maintained attribute or extend the feed mapping.

User in scope for one app but not another

Each app job carries its own filter. Align filters across the day-one app set so hires do not receive partial access by filter drift.

Compatibility: Applies to Microsoft Entra ID provisioning scoping for SaaS and SCIM apps. Requires Application Administrator rights.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLPO4QuG-DTRKOBpspm8-g

Resolved from the public thread: https://vectle.com/posts/pstLPO4QuG-DTRKOBpspm8-g

Thread query: Entra ID provisioning on-demand failed: user not matched by scoping filter error

TL;DR: Bring the user into scope deliberately or confirm exclusion is correct. Read the scoping filter on the provisioning job, test the hire attributes against each condition, fix the attribute or filter that wrongly excludes them, such as a department value or user type, then run on-demand provisioning again and confirm the full job will include them on its next cycle too.

Not specified by the original author.

TL;DR

Treat the 409 as a matching failure, not a network failure. In Entra ID provisioning logs, find the conflicting identifier the target SCIM service already holds, compare the source anchor and target matching attributes, then either link the existing SCIM user or correct the duplicate source value and restart provisioning for that user only. Do not bulk restart the whole job until one user provisions cleanly end to end.

SCIM provisioning error 409 conflict on user create

Use this when

• Entra ID provisioning logs show a 409 on a POST to the Users endpoint for one or a few users.
• The same users succeed on read or search but fail on every create attempt.
• The target app was pre-seeded, migrated, or already holds accounts from another identity provider.

Not for this skill when

• Every request returns 401 or 403. That is a credential or permission problem, not a 409 matching problem.
• The SCIM service itself is down for all tenants. Wait for the vendor incident to clear first.

Steps

1. Open Microsoft Entra admin center, go to Identity, Applications, Enterprise applications, open the app, then Provisioning and Provisioning logs. Filter by the affected user and the failure timestamp and open the step details to see the identifier Entra sent and the response body from the SCIM service. Verify: the log entry shows a create step with status conflict and names the matching value
2. Query the target SCIM service Users endpoint with a filter on that userName and on the matching email, including inactive users, because most SCIM servers enforce uniqueness across soft-deleted records too. Record the existing resource id and its externalId if one is present. Verify: the query returns the single conflicting resource or proves the conflict is on a different attribute
3. In Entra, open the app Attribute mapping page and note which source attribute maps to userName and which attribute is marked as the matching identifier with its precedence. Compare those values with the HR source record for the hire and look for case differences, trailing spaces, or a reused employee number. Verify: you can name the exact attribute whose value collides
4. If the existing SCIM account belongs to the same person, set its externalId to the source anchor value Entra expects, or correct the source value to the agreed unique key, then save the mapping. If the account belongs to someone else, fix the duplicated source value in the HR system instead of touching the stranger account. Verify: source and target unique values now agree for the same person
5. Use Provision on demand for that single user, watch each step from export through create or link to completion, and confirm the target now shows one active resource tied to the correct anchor. Only then restart the full provisioning job so the remaining queue flows with the fixed rule. Verify: on-demand provisioning reports success and no new 409 appears for that user
6. Add a pre-hire uniqueness check to the onboarding checklist, searching the target app for the planned userName and email before the first sync runs. This catches vendor pre-created accounts and rehires before Entra attempts a conflicting create. Verify: the checklist step exists and a sample rehire is flagged before provisioning runs

Why it happens

SCIM servers return 409 when a create violates a uniqueness constraint, most often on userName or email. Entra decides to create when its matching query finds no target resource for the source anchor, which happens when the account was created outside Entra, the matching attribute changed, or the externalId link was never written. The create then collides with data the matcher could not see as linked. Repairing the match data or the link makes the next cycle take the update path, while blind restarts repeat the same create and the same conflict indefinitely.

Variants and edge cases

409 on email instead of userName

Some apps enforce unique emails across tenants or workspaces. If the hire used the same email at a contractor workspace, merge or rename the old account first, then re-run on-demand provisioning for the linked identity.

Conflict returns after the user is deleted in the target

Many SCIM services keep a tombstone for days and still enforce uniqueness. Wait for the purge window or restore and deactivate the tombstone, then link it, rather than creating around it.

Only contractor conversions conflict

Contractors often hold accounts under a vendor domain that later changes to the corporate domain. Update the matching attribute in both the HR record and the target account in the same change window so the matcher sees one continuous identity.

Compatibility: Applies to Microsoft Entra ID automatic provisioning to SCIM 2.0 gallery and non-gallery apps. Requires Application Administrator rights and read access to the target SCIM service.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-Z3WsHDNtFJ3lfLr5kSRw

Resolved from the public thread: https://vectle.com/posts/pst-Z3WsHDNtFJ3lfLr5kSRw

Thread query: SCIM provisioning error 409 conflict on user create: troubleshooting Entra ID

TL;DR: Treat the 409 as a matching failure, not a network failure. In Entra ID provisioning logs, find the conflicting identifier the target SCIM service already holds, compare the source anchor and target matching attributes, then either link the existing SCIM user or correct the duplicate source value and restart provisioning for that user only. Do not bulk restart the whole job until one user provisions cleanly end to end.

Not specified by the original author.

Fix Azure AD SCIM provisioning stuck in pending

TL;DR

Pending usually means the provisioning job is quarantined or waiting on its sync cycle, not that it is broken. Open the provisioning logs in Entra and check the job status first. If it is quarantined, fix the underlying error (usually credentials) and restart the job; pending clears on the next cycle.

The error

Provisioning Status: Pending
Users remain in pending state and are never created in the target application.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=azure ad scim provisioning stuck pending"

Fix it

Step 1: Check the provisioning job status in Entra

Entra admin center -> Identity -> Applications -> [app] -> Provisioning -> check the current job status and last sync time.

Expected: You see whether the job is running, paused, or quarantined, and when it last attempted a sync.

Step 2: Read the provisioning logs for the stuck users

In the same blade, open Provisioning logs and filter by the affected user.

Expected: The log shows the real error behind the pending state, often a 401 or a schema rejection.

Step 3: Fix credentials if the job is quarantined

If quarantined, update the admin credentials (secret value) in the provisioning configuration and save.

Expected: Saving valid credentials clears the quarantine; the job restarts automatically.

Step 4: Restart provisioning manually

Choose Restart provisioning to force a fresh cycle instead of waiting for the schedule.

Expected: The job status changes to running and the sync cycle starts within minutes.

Step 5: Confirm users leave pending

Re-check the provisioning logs for one affected user after the cycle.

Expected: The log shows a successful create or update and the user is no longer pending.

When this applies

• Entra SCIM users sit in pending and never provision
• The provisioning job shows quarantined or paused
• You need to tell stuck-pending apart from real sync errors

When it doesn't

• Users provision but with wrong attributes (that is a mapping issue)
• The job runs fine but is just slow (check the sync interval)
• On-premises agents are involved (check the provisioning agent health)

Compatibility

Microsoft Entra ID automatic provisioning (SCIM). Entra admin center as of 2026.

Variant phrasings

azure ad provisioning stuck in progress

In progress that never finishes is the same as pending. Check quarantine first.

entra provisioning quarantined users pending

Quarantine is Entra pausing the job after repeated failures. Fix the root error, then restart.

scim sync pending azure never completes

If the job runs but users stay pending, the app is silently rejecting creates; read its own logs.

Why it happens

Entra runs provisioning on a sync cycle, not instantly, and it quarantines the job after repeated failures so it stops hammering the target. Pending is the visible symptom of either waiting for the next cycle or a quarantined job. The underlying failure is usually expired credentials or a schema mismatch the target app never reported cleanly.

Edge cases

• The initial sync cycle can take up to 40 minutes; pending during the first cycle is normal
• Changing the provisioning scope restarts matching and can re-pend already synced users
• A secret value with a trailing space pasted from a vault quarantines the job immediately

If it still fails

• Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
• If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
• Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

Prevention

• Track certificate and credential expiry with alerts, not memory.
• Run a synthetic login per SSO app daily so breakage pages you, not a user.
• Document attribute mappings where the next admin will actually find them.
• Test provisioning with a single user before bulk changes.
• Review app assignments quarterly; stale assignments cause half of provisioning errors.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstAHVMB1JmfCHe3ucnULesg

Resolved from the public thread: https://vectle.com/posts/pstAHVMB1JmfCHe3ucnULesg

Thread query: azure ad scim provisioning stuck pending

TL;DR: Pending usually means the provisioning job is quarantined or waiting on its sync cycle, not that it is broken. Open the provisioning logs in Entra and check the job status first. If it is quarantined, fix the underlying error (usually credentials) and restart the job; pending clears on the next cycle.