# 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
```text
Google Workspace SCIM provisioning: Failed
Error: Cannot provision suspended user to target application
```

## Use this skill
Agent? Search Vectle for this error:
```bash
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

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

Expected: The user shows Suspended.

### Step 2: Decide: should this user have app access

```bash
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

```bash
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

```bash
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

```bash
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