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) which identity they correlate to (ownership). A rule is a set of conditions — every account or identity 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-')"}.

Ownership rules

Ownership rules link an account to an identity. A rule has conditions that compare identity fields against account fields:

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

For Entra-style environments, email == UPN works out of the box in about 90% of cases.

Multiple rules per type — priority

A single type can have multiple rules. The engine evaluates them in priority order (lowest first); the first match wins. Example use case:

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.

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: