The Identity Dataplane
AOH Sync's identity model is the authoritative record of who exists across your connected systems. This page describes precisely how AOH Sync represents identity data, how it resolves conflicts when the same attribute appears in multiple sources, and how normalized identity data flows to Microsoft Entra ID.
Core concept: the Identity aggregate
An Identity is the top-level object that represents a real person (or a non-human principal) across all the systems you have connected to AOH Sync. A single Identity can have many constituent parts because most enterprise environments spread identity data across multiple systems. For example, a person might exist as a User record pulled from your HR system, one or more Account records in your directories or SaaS tools, and one or more Machine Identity records if they own service accounts or shared mailboxes.
The four component types that an Identity aggregates are:
User
The person record as read from a Source System. Carries core profile data: user_principal_name, display_name, email, job_title, status, hire_date, roles, groups, and department memberships.
Account
A directory or application account that belongs to the identity. An Account is linked back to the Identity via a person_id reference and carries its own identifier, status, and source_system_id.
Machine Identity
A non-human principal (service account, shared mailbox, robot user) that is owned by or associated with this identity. Machine Identities carry a classification, an owned_by reference, a manager_id, a technical_inheritor, and a computed risk_score.
Identity Attribute
A single resolved key-value pair — for example, job_title = "Senior Engineer" — with full provenance metadata describing where the value came from and which source wins when there is a conflict.
The Identity object itself carries id, display_name, status, created_at, and updated_at timestamps, plus the four arrays above.
Attribute conflict resolution: source, priority, and provenance
When you connect multiple Source Systems to AOH Sync, the same attribute (e.g., job_title or department) may arrive from more than one source with different values. AOH Sync resolves conflicts through the IdentityAttribute model, which attaches provenance metadata to every resolved attribute value.
Each IdentityAttribute record carries:
field_name
The attribute being resolved (e.g., job_title).
field_value
The winning value after conflict resolution.
source_type
The category of system the value came from (e.g., your HR connector, a directory connector).
source_id
The specific Source System instance that supplied this value.
priority
An integer that determines precedence when multiple sources supply the same field_name. Lower numbers indicate higher authority.
updated_at
When this attribute value was last written, for audit trail purposes.
When two sources supply the same field_name, AOH Sync retains the value from the source with the lowest priority number (highest authority). The losing value is not stored — only the winning value and its provenance are persisted. This means every attribute you see in AOH Sync is traceable back to the exact Source System that supplied it.
Graph model: how entities relate
AOH Sync stores the identity graph in a property graph database (Neo4j), where nodes represent identity entities and directed edges represent relationships. The key relationships are:
Membership edges carry from and until timestamps, so AOH Sync maintains a temporally accurate record of when a user joined or left a group or department — useful for access-review and audit purposes.
Identity lifecycle events (joiner, mover, leaver) are linked both to the User that caused them and to each other in a time-ordered chain via the NEXT relationship, making it possible to reconstruct the full history of any identity's lifecycle transitions.
Data flow: source to Entra
The path from a raw record in your Source System to a provisioned object in Microsoft Entra ID passes through three stages:
Stage 1 — Ingest and normalize. Connectors pull records from Source Systems (Microsoft Graph delta queries, SQL databases, REST endpoints, SFTP/CSV files). Raw records are converted to the AOH Sync domain model (User, Group, Department objects), deduplicated, and written into the identity graph.
Stage 2 — Conflict resolution. When the same identity appears in multiple sources, the IdentityAttribute priority model determines the authoritative value for each field. The resolved Identity object — with its Users, Accounts, Machine Identities, and winning Attributes — becomes the canonical record.
Stage 3 — Provision to Entra. The canonical identity data is formatted as SCIM Bulk Upload operations and sent to Microsoft Entra ID via the Microsoft Graph API. Attribute mappings (which you configure per Entra target) control exactly which normalized fields are written to which Entra attributes.
Lifecycle events
AOH Sync tracks three lifecycle event types for every identity:
joiner
A new identity has appeared in at least one Source System.
mover
An attribute that signals a role or department change has been updated.
leaver
The identity has been deprovisioned or disabled across its connected sources.
These events are stored in both the identity graph (for graph-traversal queries) and a relational store (for efficient time-range queries and audit export). Each event carries a structured details payload and a timestamp.
Related
Last updated