Why digital business cards belong in your identity lifecycle
Most digital business card platforms treat the employee roster as a file you upload. You export a CSV from your HR system, map the columns, import it, and the data is correct until the next person is hired, promoted, or leaves — which is usually the same week. The roster then drifts, quietly, until someone notices a card for a person who left in March.
Treating cards as an identity-governed resource removes that drift entirely. Okta already knows who works here, what their title is, which department they sit in, and — critically — the exact moment they stop working here. SCIM is the standard that lets Okta tell downstream applications the same thing it tells Slack and Zoom. A digital business card is a published, externally-facing representation of an employee; it has at least as much claim to lifecycle management as an internal chat account.
The security argument is the one that usually closes the deal internally. A digital business card is a public URL carrying a name, a job title, a company, a direct phone number, and an email address. Left live after termination, it is a working credential for social engineering — and unlike a Slack account, nobody gets an alert when it is used.
How QRBold maps Okta attributes onto a card
Every card is built from a template that carries a directory map: a set of rules saying which directory attribute fills which field on the card. The defaults handle a standard business card without configuration.
- givenName → First name. The user's given name as Okta holds it.
- surname → Last name. Family name, kept as a separate field so cards can be sorted and searched.
- jobTitle → Title. The line under the name. This is the attribute most likely to change mid-tenure, and the one most visibly wrong when it drifts.
- department → Department. Also usable as a grouping axis, so each department can carry its own card design.
- mail → Email address. Populates the tap-to-email action on the card.
- mobilePhone → Phone number. Populates tap-to-call. Left blank on the card if the directory value is empty, rather than rendering an empty row.
Provisioning modes: matching the rollout to the org
A blanket "everyone gets a card" rollout is the right answer for a 40-person company and the wrong answer for an enterprise where only a fraction of staff meet customers. QRBold exposes five modes so the rollout shape is a policy decision rather than a product constraint.
- Everyone. Every provisioned user receives a card. Simplest to reason about, best for small and mid-size organisations.
- By group. Only members of the Okta groups you nominate. The usual choice for enterprises — Sales, Customer Success, Field Engineering, Executive.
- Selected users. An explicit list. Useful for pilots and for phased department-by-department rollouts.
- Self-service. Anyone who can sign in may claim a card. Removes IT from the request path without giving up branding control, since the template still governs the design.
- Request with approval. Users request; an administrator approves. The right control when cards carry a cost per seat or when brand governance is strict.
What happens when someone leaves
Okta deactivation triggers the deprovision action you configured, and the choice between the three is a genuine policy decision rather than a default worth accepting blindly.
"Suspend" keeps the card record and its scan history but takes the public page offline — the right default for most organisations, because it is reversible and preserves analytics. "Delete" removes the card entirely, which some data-retention policies require. "Keep" leaves the card live and is appropriate only in narrow cases, such as a contractor whose card is deliberately maintained past the end of an engagement.
Whichever you choose, the action is automatic. The point of connecting an identity provider is that offboarding stops depending on anyone remembering to do it.