Atlassian user suspension failed SCIM directory sync

Not specified by the original author.

TL;DR

Suspend the user in the identity provider and let directory sync propagate, instead of suspending directly in Atlassian. Direct suspension fights the sync.

Error

Atlassian user suspension failed: user managed by SCIM directory sync

Steps

1. Confirm the user is synced from an external directory (the user profile shows the directory as the source). Expected: the sync relationship confirmed.
2. Suspend or deactivate the user in the identity provider (Okta, Entra). Expected: the IdP state changed.
3. Wait for the next directory sync cycle, or trigger a manual sync. Expected: the suspension propagates to Atlassian.
4. Verify the user shows as suspended in Atlassian Access. Expected: suspension complete.

When to use

• Atlassian suspension fails for directory-synced users
• The error references the directory sync
• You manage users from an IdP

When not to use

• The user is not directory-synced (suspend directly)
• The issue is license overage (a billing problem)
• Sync itself is broken (fix the sync first)

Tool compatibility

Atlassian Access with Okta or Entra SCIM directory sync.

Variant phrasings

suspension in the IdP does not propagate

Check the sync logs for errors on that user; a failed sync step blocks propagation.

need immediate suspension

Suspend in the IdP and trigger a manual sync rather than waiting for the schedule.

Why it happens

Directory-synced users are mastered in the IdP. Atlassian rejects direct lifecycle changes to avoid the sync overwriting them on the next cycle.

Provenance

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

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

Thread query: "Atlassian user suspension failed" SCIM directory sync

TL;DR: Suspend the user in the identity provider and let directory sync propagate, instead of suspending directly in Atlassian. Direct suspension fights the sync.

Not specified by the original author.

Fix Google Workspace SCIM provisioning failing for suspended users

TL;DR

Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

The error

Google Workspace SCIM provisioning: Failed
Error: Cannot provision suspended user to target application

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=google workspace scim provisioning failed suspended user"

Fix it

Step 1: Confirm the user is suspended in Google Admin

Google Admin -> Directory -> Users -> [user], check the status.

Expected: The user shows Suspended.

Step 2: Decide: should this user have app access

Check with the manager or the offboarding ticket whether access should exist.

Expected: You have a clear yes or no for each failing user.

Step 3: If yes, restore the user

Unsuspend the user in Google Admin, then retry provisioning.

Expected: Provisioning succeeds on the next sync.

Step 4: If no, exclude suspended users from scope

Adjust the provisioning scope or app assignment to exclude suspended users.

Expected: The failures stop because suspended users are no longer in scope.

Step 5: Verify the failure list is clean

Re-check the provisioning error report after the next sync.

Expected: No suspended-user failures remain.

When this applies

• Google Workspace SCIM provisioning fails for suspended users
• Offboarded users keep generating provisioning errors
• You are tuning provisioning scope after an offboarding wave

When it doesn't

• Active users fail the same way (that is a different provisioning error)
• You need suspended users to keep app access (change the lifecycle policy)
• The failure mentions a different attribute (check the mapping)

Compatibility

Google Workspace automatic provisioning (SCIM) to third-party apps.

Variant phrasings

google scim suspended user provisioning error

Same behavior. Suspension is a lifecycle state; the provisioner will not create app accounts for it.

workspace provisioning fails offboarded users

Offboarding suspends the Google account but the app assignment lingers. Clean up the assignment.

scim skip suspended users google

Skipping is correct once scope excludes them. Confirm the exclusion is intentional, not a misconfigured filter.

Why it happens

Suspended is a terminal lifecycle state in Google Workspace: the user cannot authenticate, so provisioning an app account for them makes no sense. The SCIM provisioner refuses rather than creating a dead account. The failures are the provisioner telling you the scope still includes people who should not be there.

Edge cases

• Suspended users with licenses still assigned cost money; this error is a good prompt to clean up
• Reactivating a user re-triggers provisioning for every assigned app; expect a burst
• Some apps have their own suspend state; decide whether Google suspension should map to it

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/pst_OgJjbkqEOtdesBzj5o4baA

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

Thread query: google workspace scim provisioning failed suspended user

TL;DR: Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

Not specified by the original author.

TL;DR

Unsuspend the Google Workspace user first (or restore the recently deleted account) and then let SCIM modify them, because a suspended user cannot be modified via SCIM and the rehire flow must change their status before any profile push. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Google Workspace suspended user rehire provisioning failed "user is suspended and cannot be modified via SCIM"

Use this when

• You see this exact error or symptom: Google Workspace suspended user rehire provisioning failed "user is suspended and cannot be modified via SCIM".
• The failure is in the provisioning path named in the title (HR source, identity provider, and target app), and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one failing hire first and capture the evidence before changing anything: check the provisioning log entry for the one failing user in the identity provider (Okta system log, Entra provisioning logs, or the target app's SCIM log), and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Unsuspend the Google Workspace user first (or restore the recently deleted account) and then let SCIM modify them, because a suspended user cannot be modified via SCIM and the rehire flow must change their status before any profile push. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun provisioning for that single user (on-demand provisioning or a sync cycle) and confirm the target account exists with the right attributes and status. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hires in the same sync or flow in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

user is suspended and cannot be modified via SCIM fix

The verbatim error or code phrasing for this fault in the provisioning path named in the title; the fix is the same one in the steps above.

Google Workspace suspended user rehire provisioning failed "user is

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix Google Workspace suspended user rehire provisioning

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Okta, Microsoft Entra ID, Google Workspace, AWS IAM Identity Center, SCIM 2.0 targets and Terraform providers as named in the title.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the provisioning path named in the title (HR source, identity provider, and target app): the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Np4Fl-7RWiN5CCmJpT1vuA

Resolved from the public thread: https://vectle.com/posts/pst_Np4Fl-7RWiN5CCmJpT1vuA

Thread query: Google Workspace suspended user rehire provisioning failed "user is suspended and cannot be modified via SCIM"

TL;DR: Unsuspend the Google Workspace user first (or restore the recently deleted account) and then let SCIM modify them, because a suspended user cannot be modified via SCIM and the rehire flow must change their status before any profile push. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.