Overview
Understand how AOH Sync models your identity data and keeps it in sync.
The Core Concepts section covers the building blocks that underlie every feature in AOH Sync. Read these pages if you want to understand why the product works the way it does — or before diving into the Feature Reference for configuration walkthroughs.
Guiding principles
A few principles shape how AOH Sync behaves throughout:
One canonical record per person. A person may appear in many systems — HR, payroll, directory, SaaS apps. AOH Sync collapses those into a single Identity and keeps every linked record attached to it. There is always one authoritative answer to "who is this person?"
Access is decided by the backend, on every request. The interface reflects what is permitted; it never grants access. When access is revoked, it takes effect immediately on the next request — there is no stale-UI window.
Everything that changes state is recorded. Every action that modifies data — provisioning a user, resolving an orphan, acknowledging an anomaly, transferring machine identity ownership — is written to the audit trail.
Risk is measured, not guessed. Orphan risk scores and posture scores are computed from explicit inputs on a defined schedule, not estimated by heuristics.
Long-running work happens in the background. Full syncs and provisioning runs are asynchronous. The interface returns immediately; you track progress from the Connectors history or Status & Logs screen.
Pages in this section
The end-to-end flow from your Source Systems to Microsoft Entra ID
How AOH Sync models a person across multiple source systems
What Source Systems and Target Systems are, and how they differ
Full, incremental, and delta syncs — when each runs and what it does
Joiner, Mover, Leaver, and Reactivation events — how AOH Sync tracks workforce changes
Who can do what inside AOH Sync, and how access decisions are enforced
Non-human accounts — service accounts, shared mailboxes, and bots — and how AOH Sync tracks them
Related
Last updated