Entra SCIM sync error SystemForCrossDomainIdentityManagementServiceIncompatible: att

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.

Clear Entra provisioning quarantine after the failure threshold

TL;DR

Microsoft Entra ID quarantines a provisioning job after too many consecutive failures - a circuit breaker that pauses all sync so a broken config does not hammer the target app. Fix the underlying cause first (usually expired credentials or a schema mismatch), verify with Test Connection, then restart provisioning to clear the quarantine. Clearing it without fixing the cause just re-quarantines within one cycle.

The error

Provisioning Service State: Quarantine
"The quarantine threshold was exceeded. Provisioning has been quarantined."
Entra admin center / Enterprise apps / [app] / Provisioning / Overview

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=azure%20ad%20automatic%20provisioning%20quarantine%20threshold%20exceeded%20error"

Fix it

Step 1: Find the repeated failure behind the quarantine

In Entra admin center, open Identity / Applications / Enterprise apps / [app] / Provisioning / Provisioning logs. Filter by status Failure over the last 24 hours and group by error.

Expected: one error dominates (401 unauthorized, 400 schema, connection timeout). That single error is the cause; the quarantine is the symptom.

Step 2: Fix the root cause

If 401/403: re-enter the admin credentials or rotate the SCIM bearer value in Provisioning / Admin credentials. If 400 schema: fix the attribute mapping. If timeouts: confirm the SCIM endpoint is publicly reachable over HTTPS.

Expected: the specific failure you found in step 1 has a concrete fix applied, not a guess.

Step 3: Verify with Test Connection

In Provisioning / Admin credentials, choose Test Connection and wait for the result.

Expected: success. If it fails here, do not proceed - the quarantine will return.

Step 4: Restart provisioning to clear the quarantine

In Provisioning / Overview, select Restart provisioning. Confirm when prompted.

Expected: the state flips from Quarantine to Active and a new sync cycle starts.

Step 5: Watch one full sync cycle

Stay on the Provisioning logs page through the next cycle and confirm new entries show Success and the failure count stays at zero.

Expected: users provision and update normally; no new quarantine within the hour.

When this applies

• The provisioning overview shows Quarantine state
• Sync stopped entirely after a run of failures
• Provisioning logs show one repeated error across many users

When it doesn't

• Individual users fail while the job stays Active (fix the per-user error instead)
• Provisioning never ran at all (check the initial configuration)
• The job is paused manually (just resume it)

Compatibility

Microsoft Entra ID automatic provisioning (formerly Azure AD provisioning service). Applies to SCIM and non-gallery app provisioning.

Variant phrasings

entra provisioning quarantined

Same state, newer name. The restart path is identical: fix cause, test connection, restart provisioning.

azure ad provisioning stopped quarantine

Check whether it stopped on its own (quarantine) versus someone pausing it. Only quarantine needs the root-cause fix first.

Why it happens

Quarantine is a circuit breaker. Entra counts consecutive provisioning failures; past the threshold it assumes the configuration is broken and stops the job rather than retrying thousands of doomed operations against the target app. One systemic error poisons the whole sync.

Edge cases

• Restarting without fixing the cause re-quarantines in the next cycle; always fix first
• Large initial syncs can trip the threshold on transient errors; narrow the scope with filters for the first sync
• Credential expiry is the top cause; set a calendar reminder before the next expiry

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

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

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

Thread query: azure ad automatic provisioning quarantine threshold exceeded error

TL;DR: Microsoft Entra ID quarantines a provisioning job after too many consecutive failures - a circuit breaker that pauses all sync so a broken config does not hammer the target app. Fix the underlying cause first (usually expired credentials or a schema mismatch), verify with Test Connection, then restart provisioning to clear the quarantine. Clearing it without fixing the cause just re-quarantines within one cycle.

Not specified by the original author.

TL;DR

Align the BambooHR field, the integration transform, and the Entra target attribute for every failing hire, starting with required attributes. Export one failing employee record, compare each mapped value against the Entra schema rules for length, format, and allowed values, fix the transform or the source field, then sync that one employee to green before resuming the schedule.

BambooHR to Entra ID onboarding sync failed: attribute mapping error

Use this when

• The BambooHR to Entra sync reports attribute or mapping errors for a subset of employees.
• Failures cluster on a department, location, or employment type that fills fields differently.
• The connection test passes and most employees sync without errors.

Not for this skill when

• No employees sync at all and the API key check fails. Repair the connection credentials first.
• The error names licenses or seats rather than attributes. Handle the license pool problem separately.

Steps

1. Open the integration sync history, find a failing employee, and list the exact attributes named in the error, including the rejected value when the log shows it. Keep that employee as the test case for every change so progress is measurable. Verify: the failing attributes and values are recorded for one named test employee
2. In BambooHR, open that employee record and read the source fields feeding those attributes, checking for blanks, free-text variations, special characters, and dates in local formats. Compare with an employee who syncs cleanly from the same department to spot the pattern difference. Verify: each failing attribute traces to a visible source value difference
3. In the Entra provisioning or HR-driven mapping for the app, open the attribute mapping and check the target rules for each failing attribute: maximum length, allowed value sets for department or location, and any expression that concatenates or truncates fields. Note where an expression can produce a value the target rejects. Verify: every failing attribute has a stated target rule to test against
4. Fix at the earliest point that owns the truth. Correct bad source values in BambooHR, fix expressions in the mapping when the source is valid but the transform mangles it, and extend the target value set when HR legitimately added a new department or location. Avoid fixing only the single employee record when a transform is at fault. Verify: the fix level matches the cause for each attribute
5. Run an on-demand sync or provision for the test employee only, confirm all attributes land correctly in Entra, and check the resulting account state, manager link, and group or license rules driven by those attributes. Verify: the test employee syncs with zero mapping errors and correct downstream effects
6. Resume the scheduled sync, review the next cycle for the same attribute names, and add the new value sets or field guidance to the HR data entry notes so future hires arrive in the expected format. Verify: the next full cycle shows no repeat of the same mapping errors

Why it happens

BambooHR fields are flexible and often free-text, while Entra target attributes enforce schemas, value sets, and length limits. The integration translates between the two, so any drift, a renamed department, a longer job title, a date format change, produces a value the target rejects and the sync labels as a mapping error. Because only hires carrying the new or unusual values fail, the problem looks random until failing records are compared side by side. Governing source values and keeping transforms and target sets in step removes the whole class.

Variants and edge cases

Manager attribute mapping fails

The manager value must resolve to an existing Entra user. Sync managers before their reports, or hold the manager link update until the manager account exists, then let the next cycle fill it in.

Date attributes rejected

Hire dates arriving as free text or in a regional format fail date-typed targets. Enforce the BambooHR date picker field for start dates and format the transform output as an ISO date with no time component.

Location values rejected after an office opening

A new office creates a location string the target set does not know. Add the value to the target set and the mapping table in the same change, then re-sync the affected location cohort.

Compatibility: Applies to BambooHR integrations feeding Microsoft Entra ID HR-driven provisioning and SCIM apps. Requires BambooHR admin access and Entra provisioning configuration rights.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstzdcieDrpHI8-6XPc54mEQ

Resolved from the public thread: https://vectle.com/posts/pstzdcieDrpHI8-6XPc54mEQ

Thread query: BambooHR to Entra ID onboarding sync failed: attribute mapping error how to fix

TL;DR: Align the BambooHR field, the integration transform, and the Entra target attribute for every failing hire, starting with required attributes. Export one failing employee record, compare each mapped value against the Entra schema rules for length, format, and allowed values, fix the transform or the source field, then sync that one employee to green before resuming the schedule.