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.

A shared type carries the settings once

The catalogue entry is the shared account type: "Administrative" is one type across every system that activates it. Settings that are naturally shared live on it (requestability and its review cadence and approval chain, creating an account on demand, credential rotation, and the leaver grace and timing), and every system's activation follows them unless that system sets its own value. Each setting resolves in one order: the system's own value, then the shared type, then the platform default.

The Account types page edits a shared type's settings and lists, per system, which settings that system sets itself; "Follow the shared type" (per system or for all of them) clears those values after a confirmation. The per-system editors say what each field follows and from where. A new activation stores nothing of its own and follows its shared type from the start. Account rules can also be scoped to a shared type, so a rule for "Administrative" is written once; see account rules.

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, and for a type that is not pre-set otherwise.

• visibility_only — accounts are synced and visible in the platform for reporting and audit, but no workflows run on them. The Entra vendor template starts its B2B guest type here.

• excluded — accounts are not synced at all (the native filter keeps them out at the source). The Entra vendor template starts its Microsoft-managed system-account type here.

💡 Tip

Not sure? Choose governance — you can always lower it to visibility_only after 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 / ai_agent / workload / 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.

Classification decides an account's type

An account's type follows its classification. Account Rules classify the account into a purpose class, and the platform then places it on the type of that purpose on its system. It never invents a type for this: a purpose with no type on the system is reported instead. A system does not get to say which type an account is, so a native filter that disagrees with a classified account does not move it. The stored type stays and the disagreement is raised as an account_type_filter_conflict finding, one per system, sent to the connector owner. The fix is a classification rule (for Entra guests, for example, on the #EXT# UPN, placed ahead of the catch-all) or the filter. An account that is new or unclassified, or one the filter agrees with, still takes the filter's type.

You can also pick the type of a single account by hand. That pick is an explicit override: account rules no longer move the account, and sync does not overwrite it. Clearing the override hands the account back to the rules.

Per-type settings after creation

Beyond scope and purpose, each type carries settings you can edit on the system's Account types panel after the type exists:

• Naming — account_name_format, set here only when this system genuinely differs from the tenant's convention (Active Directory's sAMAccountName, for example, carries no domain). Unset, the type follows the tenant-wide default for its purpose class. The setup journey's Decide phase proposes these defaults, per purpose class, from the accounts the synced systems already hold (with how many accounts each format fits and misses), including a per-system override where a system differs and a system that caps names at a fixed length; an administrator accepts a proposal as shown or edited. A per-system override goes on the type that classification and provisioning use. Only when neither is set does the name fall back to [BIZID], and the screens say so. A format can read identity attributes, for example {slug(first_name)}.{slug(last_name)}@example.eu or {localpart(email, business_id, 20)}; the tokens [EMAIL], [ACCOUNTNAME] and [BIZID] still work.
• Write home — the OU or container where new accounts of this type are created. Unset inherits the connector's base.
• CN format (directory systems) — the common name of a new directory account, with {account_name} for the unique login. This keeps two people with the same display name from colliding on the same entry.
• Leaver grace — a per-type override of the tenant's leaver grace, for example to keep shared mailboxes longer. The grace applies to a terminated identity only. When an active person's account stops being demanded by their access, it is disabled in the same run with no grace, and deleted after the usual disable-then-delete period.

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:

• Account Rules
• Read/Write Parity
• Provisioning Mappings