What SCIM actually does
SCIM — System for Cross-domain Identity Management — is an open standard that defines how an identity provider tells an application about users and groups. It specifies a REST API, a JSON schema for representing a user, and the operations for creating, updating, and deactivating one. Because it is a standard, an IdP can provision any compliant application without a bespoke connector, and an application can be provisioned by any compliant IdP without knowing which one it is talking to.
Without SCIM, keeping a downstream application in step with the directory means one of three things: somebody exports a CSV on a cadence, somebody writes and maintains a script against a proprietary API, or nobody does anything and the application drifts. All three are common. The third is by far the most common.
For digital business cards the drift is unusually visible, because the artefact is public. A wrong job title on an internal dashboard is an annoyance. A wrong job title on a card that a customer scanned at a conference is a small but real credibility problem, and a live card for someone who left six months ago is a security one.
Why provisioning and SSO are separate switches
It is tempting to treat single sign-on and provisioning as one feature — both connect to the identity provider, both are configured by the same admin, both appear on the same settings page. They answer different questions, and conflating them causes real confusion during rollout.
SSO answers "who may sign in." Provisioning answers "who receives a card." Those populations are frequently different: an organisation might allow everyone to sign in while issuing cards only to customer-facing teams, or run a pilot where cards exist for fifty people while SSO is already live for everyone.
QRBold keeps them as separate switches with separate status. A connection can have SSO verified and provisioning switched off, which is a perfectly normal state during a staged rollout and one that a merged design would render as a confusing half-configured warning.
Provision states and what they mean
Every user under provisioning carries a state, and knowing which is which makes troubleshooting a rollout much faster.
- None. The user exists but falls outside the provisioning rule — not in a nominated group, or not selected. No card, and none expected.
- Eligible. The rule covers this user and a card would be created, but it has not been yet. This is the normal steady state under first-login provisioning.
- Provisioned. A card exists and is live. The expected state for anyone in scope after a completed sync.
- Suspended. The card exists but its public page is offline, normally because the IdP deactivated the user. Reversible — reactivating in the IdP restores it.
- Revoked. Access has been withdrawn deliberately. Distinct from suspended because the cause is an administrative decision rather than a directory event.
Rotating a SCIM token without downtime
A SCIM token is a long-lived credential with the power to create and deactivate users, which makes rotation a normal part of running it rather than an emergency procedure. QRBold supports several active tokens on one connection specifically so rotation does not require an outage window.
The sequence: mint a new token with a fresh expiry; update the identity provider to use it; wait for a sync cycle and confirm the new token's last-used timestamp is advancing while the old one's is not; revoke the old token. Each token shows its prefix and last four characters, so identifying which credential a given IdP connection is using does not require reading the secret itself.