SCIM operations

Per-organisation scale caps, throttling behaviour, drift detection, and the runbooks for operating SCIM provisioning at scale.

This page covers the operations side of SCIM — what to do when you're approaching scale caps, how throttling works, how to detect and reconcile drift, and the runbooks your platform team needs.

For setup and provisioning behaviour, see Identity & Provisioning and the per-IdP guides (Entra, Okta, OneLogin).

Scale caps (recap)

Resource	Cap
Users per organisation	10,000
Groups per organisation	1,000
Members per group	2,000
Nested group depth	3 levels
SCIM API requests	20 per second per organisation

These are guardrails on shared infrastructure, not architectural ceilings. If your organisation needs higher limits, contact support and we'll provision a dedicated rate-limit profile.

When your IdP exceeds 20 requests/sec, the platform returns 429 Too Many Requests with a Retry-After header. Every IdP supports Retry-After natively, so you generally don't need to do anything — the sync slows down and catches up.

What to watch for:

Bulk provisioning storms — assigning a 5,000-user IdP group to the Scrydon app for the first time will hammer the rate limiter. Expect the initial sync to take roughly 5,000 / 20 = ~4 minutes plus overhead. Subsequent delta syncs are fast.
Frequent group-membership churn — every membership change triggers a sync write. If your IdP has a noisy group, consider whether the group really needs to be Scrydon-assigned.
Multiple IdP integrations — the 20 req/s cap is per organisation, not per IdP. If you run two IdPs against the same Scrydon org (uncommon but supported), they share the budget.

The rate-limit headers are informational and visible in the IdP's sync logs. Most IdPs surface 429s as "transient errors" that auto-retry — they don't break the provisioning state machine.

Bulk provisioning runbook

When onboarding a new organisation or moving thousands of users into Scrydon for the first time, follow this sequence:

Reserve a sync window. A 5,000-user push takes minutes; plan around your IdP's freshness expectations.
Stage the IdP groups. Create the groups in your IdP with the desired members before assigning them to the Scrydon app. SCIM only sees what's assigned, so staging keeps the sync deterministic.
Assign the Scrydon app. This triggers the initial sync.
Watch the audit log. Filter on scim.* actions; you should see a steady stream of scim.user.provisioned, scim.group.created, scim.group.member.added.
Verify a sample. Once the sync stabilises, pick 10 random users and confirm they can sign in.

If the sync stalls, check the audit log for scim.error.* events — these carry the IdP's response body and the specific user / group that failed.

Drift detection

"Drift" means the workspace's actual membership has diverged from what the IdP says it should be. This can happen when:

An admin manually edits workspace membership in Scrydon (overriding what SCIM says).
The IdP fails an SCIM call and doesn't retry (rare with modern IdPs, but happens).
A user is renamed at the IdP but the new email collides with another user in Scrydon.

To check for drift on demand:

Go to Settings → Platform → Identity & Provisioning → Drift report.
Click Run scan. The scan compares each SCIM-linked team's membership in Scrydon to the IdP's view.
Review the report. Each entry shows the user, the workspace, and what the discrepancy is.

You can fix drift two ways:

Reconcile to IdP — accept the IdP's view as truth, push it to Scrydon. Use this when the IdP is authoritative (which is the normal SCIM pattern).
Manual fix — fix the underlying cause (rename a user, repair the email collision) and re-run the IdP's sync.

Common scenarios

The user has been provisioned (a Scrydon user record exists) but is not actually signing in. Most common cause: SSO is not yet configured between your IdP and Scrydon. SCIM creates the record; SSO authenticates the session. Both are required.

Check Settings → Platform → Identity & Provisioning → SSO is configured for the same IdP that's running SCIM.

A user was deprovisioned but I can still see them in Scrydon

Deprovisioning is a soft delete — the account is banned, sessions are revoked, org membership is removed, but the underlying user record is preserved for audit purposes. You'll still see them in audit-log queries; you won't see them in the active users list and they can't sign in.

If you genuinely need to hard-delete a deprovisioned user (e.g. GDPR right-to-erasure), use Settings → Platform → Privacy → Subject erasure — see GDPR.

A user was re-provisioned after deprovisioning

If the same user is re-added to the IdP later, SCIM automatically reactivates the original record — same userId, audit history continuous, no duplicate. This is a feature: your audit trail stays whole across the lifecycle.

"Email conflict" on provisioning

The user is being created with an email that already exists in the organisation under a different SCIM externalId. This shouldn't happen unless an admin manually changed an email after provisioning, or the IdP changed how it identifies the user. Resolve at the IdP first; SCIM is the downstream party here.

Token revoked or expired

SCIM tokens are sensitive credentials and have no automatic refresh. Rotate them yearly (or per your security policy), and on any suspected exposure.

To rotate:

Settings → Platform → Identity & Provisioning → SCIM tokens → Generate new token.
Copy the new token into your IdP's SCIM configuration.
Confirm the next IdP sync succeeds with the new token.
Revoke the old token.

Plan rotation around a quiet sync window — your IdP will see auth failures during the brief overlap.

Audit events

Every SCIM action emits a structured audit event. Common ones:

scim.token.created / scim.token.revoked
scim.user.provisioned / scim.user.updated / scim.user.deactivated / scim.user.reactivated
scim.group.created / scim.group.updated / scim.group.deleted
scim.group.member.added / scim.group.member.removed
scim.error.invalid_token / scim.error.scale_cap_hit / scim.error.email_conflict

Filter the audit log on the scim.* prefix to see all SCIM activity. Forward to your SIEM via the SIEM forwarder.

Limits in detail

Worth knowing precisely:

Cap	Behaviour at the limit
Users per organisation	Provisioning beyond the cap returns `409 Conflict` with `limit_reached`. Existing users are unaffected.
Groups per organisation	Same as users — additional groups return `409`.
Members per group	Additional `add` operations return `409`. The first 2,000 members remain.
Nested group depth	Groups containing a 4th-level nesting are flattened with a warning — the deeper members are ignored.
SCIM API requests	Bursts return `429 Too Many Requests` with `Retry-After`.

All caps are configurable per organisation if your scale demands it. Contact support.

Identity & Provisioning (SCIM) — provisioning model and supported IdPs.
Hard fencing — restrict system credentials to specific groups.
Audit logging — where SCIM events land.
Audit events catalogue — full event reference.
SIEM forwarding — push SCIM events to your SIEM.