Account Rules

Classification and ownership rules, with priority-based multi-rule handling per type.

What are Account Rules?

Account Rules determine (a) which accounts belong to which type (classification) and (b) who is responsible for an account (correlation). There are two rule kinds, classification and correlation; a separate ownership rule kind no longer exists, because "who is this account's responsible party" is one question. A rule is a set of conditions — every account that matches receives the rule's effect.

Classification rules

A classification rule has a list of conditions built from fields on the account itself:

• attributes.userType eq 'Member' — Entra style
• native_account_name starts_with 'a-' — user principal name (UPN) pattern
• attributes.accountEnabled eq true

Conditions combine with AND or OR. Need more complex logic? Use a Jinja escape: {"account.native_account_name.startswith('adm-')"}.

Correlation rules

A correlation rule has two modes.

Match links an account to an identity by comparing identity fields against account fields:

• identity.email == account.userPrincipalName (lower)
• identity.employee_id == account.attributes.workdayId

An exact, unique match links the account automatically; anything else becomes a proposal for a person to confirm. For Entra, the catalogue ships email == UPN as its default match, which fits tenants whose UPN follows the e-mail address; tenants with a different convention adjust the rule.

Reference assigns one fixed target to every account its conditions select, in bulk: a specific identity (a person or a non-human identity), a role, or the system owner. An identity target links the account to that identity. A role or system-owner target writes an ownership record for the account and leaves the account's identity empty, so joiner/mover/leaver and SoD logic that read the identity link are unaffected. A reference rule applies immediately and never raises a proposal. It only fills gaps: an owner someone already set on the account is left alone, so re-pointing a rule does not move accounts it already assigned (clear their owner and the next recompute applies the new target). An account that already has an identity link is not re-evaluated by any correlation rule. The rule editor tests a rule before it is saved and reports what it would do without writing anything.

An account's owner follows the cascade: an explicit ownership record first, then the correlated identity (a person owns their own account; a non-human account follows that identity's owner), then the rest bucket. Coverage reads the same way: an account with no responsible party is an orphan, then unlabeled, then governed.

Multiple rules — scope first, then priority

A system can have several rules. The engine evaluates them in order and the first match wins, so the ordering is the logic. Two things decide it, in this sequence:

1. Scope. A rule written for one account type on one system is considered first, then a rule written for a shared account type (one type across systems, such as "Administrative"), then one written for a system, then a tenant-wide rule. A narrower rule always pre-empts a broader one, whatever its priority number.
2. Priority within that scope — lowest number first.

• Rule 1 (priority 10): "Privileged admin pattern" — UPN starts_with 'a-' → type personal-privileged
• Rule 2 (priority 100): "Default" — all other Members → type personal

💡 Tip

For legacy or migrated accounts that do not follow the current naming convention: add an extra rule with a lower priority and a tailored pattern. The engine matches that rule first, and the old account still receives the correct type and owner.

Global rules first, and where they reach

A tenant-wide rule is written against the platform's own field names (the canonical keys, such as account.account_kind), so the same rule reads the same field on every system; a new tenant-wide rule that reads a system's raw attributes.* is refused with the canonical alternative named. Each system's Data model tab has an Identity matching pane: the rules that apply to that system, the field each rule attribute reads there, how much the global rules carry, and an editable attribute mapping. Rule mining proposes tenant-wide rules first.

Every link records which rule made it. The Rules tab shows how far the global rules carry the tenant and where each rule runs; a rule is tested in its own dry run before it is edited. The Insight tab leads with why accounts are unlinked: its figures show their denominator, and identical triage questions are grouped, so one classification can settle a whole group at once.

Correlation runs before classification

Within a single pass the engine correlates first, then classifies. That ordering is not incidental: rules can test the correlated identity — is this account linked to anybody at all, and if so is that a person or a machine — and neither question can be answered before the link is resolved.

It is what makes the tenant-wide defaults sensible rather than arbitrary. Out of the box, an account correlated to a service, system, application, AI-agent or device identity classifies as a service account, and an account correlated to anybody else classifies as personal. Only the non-human side enumerates identity types, so a new human type falls through to personal on its own; a new machine type is a deliberate addition.

The account type follows the classification

Classification, not the target system's native filter, decides an account's type. The recompute moves an account to the type that matches its class, but it never creates a type for it: a class with no matching type on the system is reported. If a type's native filter disagrees with an account's classification, the account keeps its type and the disagreement is shown as a configuration error on the run and as an Advisor finding per system, instead of the account flipping type on every sync. A person can override the type on a single account; that choice holds until it is cleared, and choosing the type the rules already give clears the override. See Account Types.

An orphan is left unclassified, on purpose

An account with no correlated identity matches neither default and keeps no classification at all.

That is a decision, not a gap. The tempting alternative — stamp it personal, since most accounts are — produces a governance model in which an account nobody owns is indistinguishable from an account belonging to a named employee. An unclassified account is a visible, countable question; a wrongly-classified one is an answer, and the wrong one. Orphans are the orphan finding's business, and this engine deliberately declines to hide them.

The same reasoning applies to the tenant-wide defaults generally: they are labelled fallbacks and sit at high priority numbers so that any rule you write pre-empts them. They exist to stop accounts falling through entirely, not to express a view about your estate.

Read/write parity invariant

Account Rules (read) and the provisioning configuration (write) MUST be aligned on the same identifier fields. If ownership says email == UPN but the write-mapping fills UPN from gen_username('first.last'), then the accounts the platform creates become orphans.

---

Further reading:

• Account Types
• Read/Write Parity
• Provisioning Mappings
• Advisor