google workspace scim provisioning failed suspended user

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