Account Types
How accounts are categorised per system, and the governance scope each category carries.
What is an Account Type?
An Account Type categorises the accounts on a single system so that governance can decide, per category, how those accounts are handled. On an identity provider (IdP) such as Entra, for example, you have personal accounts, business-to-business (B2B) guests, administrative accounts and system accounts — each with its own governance need.
For each type you define:
- Scope — governance / visibility_only / excluded
- Native filter — a system-specific query (OData / SCIM / SQL) that issues a separate API call per type
- Default identity type — which identity type accounts receive on auto-correlation
- Write attributes — which target fields the platform is actually allowed to write
A type is a purpose, never a lifecycle state. A disabled personal account is still a personal account: whether it is switched on is tracked separately on the account, and modelling "disabled" as its own type would move an account between categories every time somebody deactivated it. The product enforces this — a vendor template naming a type after a state fails a test rather than shipping.
The categories are the tenant's, not the connector's
Account types are catalog-first. Your tenant has one catalogue of account types, seeded with five standard entries — Unknown, Personal, Administrative, Service account and Guest — which you extend with any category your organisation actually uses. Connecting a system does not invent categories: it activates catalogue entries on that system, and adds a genuinely new type only when the catalogue has nothing for that purpose.
This sounds like housekeeping. It is not, and the reason is worth stating plainly, because we got it wrong first. Three separate places used to create account types — the sync that meets an unclassified account, the onboarding wizard applying a vendor template, and the catalogue's own "activate on this system" action — each with its own naming convention and none aware of the others. The result on a live tenant was two personal types on one connector: an auto-minted one holding 481 accounts, and the catalogue type an administrator had deliberately activated, holding none. Everything synced landed on the type nobody had chosen, and the configuration the administrator had done sat there doing nothing. Nothing errored. The tenant simply had two answers to one question, and the wrong one was winning.
There is now exactly one creator, and it reuses before it creates: an existing type of the same purpose on that system wins, with a catalogue-linked type outranking anything auto-minted; failing that it instantiates the catalogue entry for that purpose, taking the name and label from the catalogue rather than a hardcoded string; and only when the catalogue genuinely has no entry for that purpose does it mint a new one. Every path in — sync, wizard, activation — goes through it.
What this buys you is that the categories in your governance model are the ones you chose. A connector can add to your vocabulary; it cannot quietly fork it.
Source systems have none
Account types exist on systems that hold accounts — targets, and bidirectional systems that are both source and target. A pure authoritative source reads identities and organisational structure; it never holds an account, so it has no account types and the panel is not offered on it. That is a single shared rule rather than a check each surface re-derives, so the panel, the activation endpoint and the sync agree about which systems can hold accounts. A system that somehow already has accounts keeps working regardless — the rule declines to create something new, it never hides what exists.
Scope — three values
-
governance — accounts are in scope for joiner / mover / leaver (JML) lifecycle, access reviews, access requests, drift detection and provisioning. The default for personal accounts.
-
visibility_only — accounts are synced and visible in the platform for reporting and audit, but no workflows run on them. The default for B2B guests.
-
excluded — accounts are not synced at all (the native filter keeps them out at the source). The default for IdP-managed system accounts.
💡 Tip
Not sure? Choose
governance— you can always lower it tovisibility_onlyafter onboarding. Raising the scope again does not retroactively re-trigger workflows.
Purpose class + account routing
Every account type carries a purpose_class (personal /
administrative / service / break_glass / permanent / contractor /
shared / guest / other). This is the same classification axis as
permission_type on entitlements, linked through the
permission_type → account-class map (default: standard →
personal, privileged/admin → administrative, service → service,
break_glass → break_glass; overridable per tenant). That map
routes a permission to the correct account: a privileged
entitlement never binds to a personal account that happens to exist.
Worked example. Say one identity has three accounts on the same system — a personal account, a B2B guest account (perhaps from an earlier contract), and a named administrative account. A policy granting an ordinary security group doesn't just need "an" account — it needs the right one:
| Entitlement | Classification | Routes to | Why |
|---|---|---|---|
| All-Staff Announcements (group) | unclassified | Personal account | Ordinary entitlements route to the personal / permanent / contractor family — this is the permissive family, so if no personal-family account existed, it would fall back to whatever the identity has rather than block. |
| Global Administrator (directory role) | permission_type: admin |
Admin account | Privileged routing is strict: no personal or guest account is ever substituted, even if one exists. No admin account → the grant is held as account_missing rather than mis-routed. |
The same rule applies identically whether the grant is issued automatically by an access policy, requested by the person through self-service, or reconciled during a routine sync — one routing decision, everywhere a grant can originate.
A contractor whose only account on that system is the guest one still receives the ordinary group above: with no personal-family account to prefer, the permissive family falls back to whichever account the identity actually has, so a lean account picture never blocks routine access.
Whether the platform may create a missing account itself is tri-state
per type (auto_create_on_demand: NULL = inherit the system default,
True = force on, False = explicit veto), with an optional override at
the entitlement-type level above it.
Relationship to Account Rules
The Account Type is the category; Account Rules are the decision logic that places accounts into or out of it. A single type can have multiple rules (first match wins, lowest priority first) — useful for legacy accounts that follow a different naming convention than the current standard.
Further reading: