One person, many accounts
An identity holds access through accounts. Each account lives on one system and belongs to at most one identity, but one identity can have many accounts: one per system it uses, and often several on the same system, such as a personal account and a separate administrative one. The platform decides per entitlement which of those accounts receives it, and it never puts a privileged right on a personal account.
An account has one owner
Sync reads the accounts on a target system. Correlation then links each account to the identity that owns it, using the system's correlation rules: typically the e-mail address against the user principal name, or an employee number against an attribute of the account. An exact, unique match links automatically; anything else becomes a proposal for a person to confirm. See Account rules.
- An account with no owner is an orphan. It stays visible and countable, and it is deliberately left unclassified rather than guessed to be personal.
- A service account can be a governed non-human identity with its own owners
and lifecycle, or simply an account classified as
service. The difference matters, and Ownership and non-human identities explains it.
Several accounts on the same system
Each account is classified by purpose: personal, administrative, service, break-glass, guest, contractor, shared and so on. The classification decides its account type, and the account type carries the governance for that category on that system.
Take one person with three accounts in Entra ID: a personal account, an administrative account and a guest account left over from an earlier contract.
| Entitlement | Goes to | Why |
|---|---|---|
| An ordinary group, such as All Staff | The personal account | Ordinary rights go to the personal family (personal, permanent, contractor). If the person has none of those on the system, they go to the account the person does have, so a lean set of accounts never blocks routine access. |
| A directory role such as Global Administrator | The administrative account only | Privileged routing is strict. No personal or guest account is ever substituted. Without an administrative account the grant waits as account missing. |
Two more settings refine the choice:
- An entitlement can name the account type it belongs to, and then only accounts of that type qualify.
- When a person has several accounts of the same type, the one marked primary wins, then the oldest.
The same routing applies wherever a grant comes from: a policy, a request or a reconciliation run.
When the right account does not exist
Whether the platform may create a missing account is set per account type, with a system-wide default and an override per entitlement type. When it may, the account is created first and the grant follows in the same provisioning batch. When it may not, the grant stays visible as account missing until someone creates the account or changes the rule.
Why an account exists, and when it goes
Accounts follow the same reasons as grants. An account exists because at least one reason does: a policy that gives everyone of a kind an account (a birthright), an approved request, or an entitlement that needs it.
- When its last reason ends, the account lapses: it is disabled after the grace period and deleted later, on the timing set per account type.
- When a status holds every reason, for example a contract on leave or a lock, the account is disabled without starting that clock, and comes back when the status ends. Nothing is deleted.
- When another reason remains, the account stays. A person with two contracts keeps an account the second contract still needs. See Employments and multi-affiliation.
The joiner, leaver and delete timing are in JML flows.
Related
- Account types: scope, purpose class and settings per type.
- Account rules: correlation and classification.
- The data model: where accounts sit in the model.