## 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
```text
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