# Welcome AOHSync is an identity visibility tool that allows customers to track an identity's attributes and entitlements across HRMS systems, Entra ID, Active Directory, and other linked systems to help organizations analyze employee identity at scale. {% hint style="info" %} New to AOH Sync? Start with [What is AOH Sync?](/readme/what-is-aohsync) or jump straight to [Getting Started](/getting-started/getting-started) to deploy your instance. {% endhint %} ## What you'll find here | Section | What it covers | | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | [Getting Started](/getting-started/getting-started) | Deploy and configure your AOH Sync instance from first login to production | | [Core Concepts](/core-concepts/concepts) | How AOH Sync models Identities, Source Systems, and Sync | | [Feature Reference](/feature-reference/dashboard) | Detailed walkthroughs of every screen in the product | | [Administration](/administration/access-management) | User management, Vault, system settings, and audit logs | | [Developer & API](/developer-and-api/developer-api) | REST API reference, webhooks, and authentication | | [Trust, Security & Data Handling](/trust-security-and-data-handling/identity-dataplane) | Where your data lives and how AOH Sync protects it | ## Related * [What is AOH Sync?](/readme/what-is-aohsync) * [Key Benefits & Use Cases](/readme/welcome) * [Getting Started](/getting-started/getting-started) # What is AOH Sync? Identity visibility for IT teams. Maps HR to Entra. Flags stale accounts and excess group access. ## How it works AOH Sync connects your upstream Source Systems (HR systems and directories) to a normalized Identity model, then continuously propagates changes to your Microsoft Entra ID target. When an employee joins, changes roles, or leaves, AOH Sync reflects that change in Entra ID — no manual tickets, no scripts, no delays. The flow has three stages: 1. **Source Systems** — AOH Sync reads Identity data from your connected HR systems and directories via Connectors. 2. **Identity model** — Incoming data is normalized into a unified Identity model that resolves conflicts and tracks relationships across sources. 3. **Entra target** — AOH Sync provisions, updates, or deprovisions Accounts in Microsoft Entra ID to match the current state of your Identity model. AOH Sync deploys as a single-tenant appliance in your own Azure subscription, so your Identity data never leaves your environment. ![AOH Sync dashboard showing 1,531 total Identities, 106 groups, and 21 departments, with department and role distribution charts, and a Top Groups by Membership list](/files/vh9iF23f2iGEqcSm2lbY) *The AOH Sync dashboard gives you an at-a-glance view of your Identity population, group counts, and distribution across departments and roles.* ## Related * [Key Benefits & Use Cases](/readme/welcome) * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Source & Target Systems](/core-concepts/source-and-target-systems) * [Getting Started](/getting-started/getting-started) # Key Benefits & Use Cases Detect stale accounts, orphan identities and excess or outdated security group memberships. ### See discrepancies and risk across the identity stack Surface stale accounts, orphaned identities, and security group memberships that are excessive or out of date. Drill down into accounts using a detailed lifecycle audit trail and access graph. ### One unified identity pipeline Mapping and reconciliation bring siloed HR and IT systems into a single view. ### Establish clear ownership for service accounts Identify the service accounts across your estate and assign a clear owner to each one. ### Azure Marketplace Deployment AOHSync runs in the customer's Azure tenant, so your identity data never leaves your trusted zone. Deployment is straightforward, allowing risk insights to arrive quickly. ## Who benefits | Team | What AOH Sync changes for them | | --------------- | ------------------------------------------------------------------- | | IT Operations | Visibility into HR (FT and Contractor) data | | Security | Risk hides in relationships | | HR / People Ops | Search new employee has a provisioned account and in correct groups | | Compliance | One view across employees and external guests | ## Common use cases ### External guest/contractor cleanup Surfaces guest accounts that were invited for a specific project and never removed. ### Visibility of orphaned accounts Finds orphaned accounts across different directories and systems. ### Role change/privilege creep cleanup Flags outdated group access left over from role changes. Identify users with excess privileges compared to peers. ## Related * [What is AOH Sync?](/readme/what-is-aohsync) * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) * [Getting Started](/getting-started/getting-started) # Overview This guide walks you through deploying AOH Sync in your Azure subscription and completing the initial configuration. Follow the steps in order — each step builds on the last. The full path from prerequisites to your first sync takes approximately **45–60 minutes**. ## What you'll need | Requirement | Details | | -------------------- | --------------------------------------------------------------------------------------------------- | | Azure subscription | With the ability to deploy a VM from the Azure Marketplace and create resources in a resource group | | A domain you control | For example, `sync.yourcompany.com`. You need the ability to add an A record with your DNS provider | | AOH Sync license key | Provided when you purchase AOH Sync. Format: `CS-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX` | {% stepper %} {% step %} [**Prerequisites**](/getting-started/01-prerequisites) Confirm you have an active Azure subscription, an AOH Sync license key, and a domain you control before you begin. {% endstep %} {% step %} [**Step 1 — App Registration**](/getting-started/02-app-registration) Create an Azure App Registration, grant the required Microsoft Graph permissions, and generate a client secret. AOH Sync uses this registration to authenticate your users via Entra ID. (\~5 minutes) {% endstep %} {% step %} [**Step 2 — Azure Marketplace**](/getting-started/03-deploy) Find AOH Sync in the Azure Marketplace, configure your deployment, and provision your VM. (\~2–3 minutes provisioning) {% endstep %} {% step %} [**Step 3 — DNS**](/getting-started/04-dns) Add an A record pointing your chosen domain to the VM's public IP address. AOH Sync configures TLS automatically once the domain resolves. (A few minutes to propagate) {% endstep %} {% step %} [**Step 4 — First Login**](/getting-started/05-first-login) Open the browser setup wizard at `https:///onboard`, enter your Azure AD credentials, and start the install. (\~10–15 minutes) {% endstep %} {% step %} [**Step 5 — Redirect URI**](/getting-started/06-redirect-uri) Return to your App Registration and add the OAuth redirect URI for your domain. This is the final configuration step before AOH Sync is live. {% endstep %} {% step %} [**Step 6 — Connect a Source System**](/getting-started/07-connect-source-system) Connect the HR or identity system AOH Sync reads people from. Adding it automatically creates an Account Import connector. (\~5 minutes) {% endstep %} {% step %} [**Step 7 — Connect a Target System**](/getting-started/08-connect-target-system) Connect your Microsoft Entra ID or Active Directory tenant. Adding it automatically creates an Identity Ingestion connector. (\~10 minutes) {% endstep %} {% step %} [**Step 8 — Set Up Provisioning**](/getting-started/09-set-up-provisioning) Create the Outbound Provisioning connector that writes identities out to your target directory. (\~5 minutes) {% endstep %} {% step %} [**Step 9 — Run Your First Sync**](/getting-started/10-first-sync) Confirm field mappings, trigger a sync, and verify the results in Sync History and the Dashboard. {% endstep %} {% endstepper %} ## Managing your instance Once AOH Sync is deployed, see [Managing Your Instance](/getting-started/11-managing-your-instance) for information on checking status, viewing logs, applying updates, and monitoring your instance. ## Need help? Contact support at **** or visit the [AOH Sync support page](/help-and-support/contact). # Prerequisites Before you deploy AOH Sync, confirm you have the following. Running through this checklist takes about 5 minutes. ## Core requirements | Requirement | Details | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Active Azure subscription | You need the ability to deploy a VM from the Azure Marketplace and create resources in a resource group | | Azure App Registration rights | You need permission to create an App Registration and grant admin consent for Microsoft Graph permissions in your Entra ID tenant | | AOH Sync license key | Your license key is in the format `CS-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX` (a `CS-` prefix followed by five groups of five alphanumeric characters). It is provided when you purchase AOH Sync | | A domain you control | For example, `sync.yourcompany.com`. You need the ability to add an A record with your DNS provider | {% hint style="info" %} If you do not have an AOH Sync license key, contact **** before proceeding. {% endhint %} ## Azure roles required You need two types of access in Azure before you begin: | Access | What it's for | | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **VM deployment rights** (Contributor or Owner on the target resource group) | Deploying the AOH Sync VM from the Azure Marketplace and creating the associated resources (public IP, NIC, disk) | | **App Registration + admin consent rights** (Application Administrator or Global Administrator in Entra ID) | Creating the App Registration and granting admin consent for the required Microsoft Graph permissions | ## VM sizing guidance AOH Sync runs on an Azure virtual machine. The Marketplace deployment form lets you choose the VM size and disk configuration. | Setting | Recommendation | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **VM Size** | **Standard\_D4s\_v3 or larger** for production. Standard\_D8s\_v3 and Standard\_D4s\_v5 are also recommended. Standard\_D2s\_v3 is the minimum allowed but is not recommended for production workloads | | **OS Disk Type** | **Premium SSD** recommended for production | | **OS Disk Size** | **64 GB minimum**; larger disks are supported | ## Admin Username During the Marketplace deployment you will choose an **Admin Username** — this is the SSH user for the VM. Note this value: you will need it if you ever SSH in to use the `cloudsync-maintenance` CLI (see [Managing Your Instance](/getting-started/11-managing-your-instance)). ## How to check you're ready Before moving on: * [ ] You can sign in to the [Azure Portal](https://portal.azure.com) and reach a subscription with Contributor or Owner rights * [ ] You have (or can request) Application Administrator or Global Administrator rights in Entra ID * [ ] You have your AOH Sync license key in the format `CS-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX` * [ ] You have a domain and access to create DNS records with your DNS provider ## Related * [Getting Started overview](https://github.com/AOHWV/docs/tree/main/getting-started/README.md) * [Step 1 — App Registration](/getting-started/02-app-registration) # Step 1 — App Registration AOH Sync uses an Azure App Registration to authenticate your users via Microsoft Entra ID. You only need to complete this step once. This typically takes about **5 minutes**. {% stepper %} {% step %} **Create the registration** 1. Sign in to the [Azure Portal](https://portal.azure.com). 2. Navigate to **Microsoft Entra ID** → **App registrations** → **New registration**. 3. Fill in the form: * **Name:** `AOH Sync` (or any name you prefer) * **Supported account types:** *Accounts in this organizational directory only* * **Redirect URI:** Leave this blank for now — you will add it after deployment in [Step 5](/getting-started/06-redirect-uri). 4. Click **Register**. {% hint style="info" %} Copy the **Application (client) ID** shown on the overview page. You will need it during the browser setup wizard in [Step 4 — First Login](/getting-started/05-first-login). {% endhint %} {% endstep %} {% step %} **Configure API permissions** 1. Go to **API permissions** → **Add a permission** → **Microsoft Graph** → **Delegated permissions**. 2. Add the following four permissions: | Permission | Type | Purpose | | ----------- | --------- | ----------------------------- | | `email` | Delegated | View users' email address | | `openid` | Delegated | Sign users in | | `profile` | Delegated | View users' basic profile | | `User.Read` | Delegated | Sign in and read user profile | 3. Click **Grant admin consent for \[your organization]** and confirm. {% hint style="success" %} All four permissions should show a green **Granted** status before you proceed. See [Entra ID Permissions](/trust-security-and-data-handling/entra-permissions) for details on why each permission is required. {% endhint %} {% endstep %} {% step %} **Create a client secret** 1. Go to **Certificates & secrets** → **New client secret**. 2. Enter a description (for example, `aoh-sync-vm`) and choose an expiry period. 3. Click **Add**. 4. **Copy the secret value immediately** — Azure will not show it again after you leave this page. {% hint style="warning" %} Store the client secret in a safe location. You will be prompted to enter it in the browser setup wizard in [Step 4 — First Login](/getting-started/05-first-login). It is **not** entered during the Marketplace deployment — AOH Sync collects it over TLS in the browser wizard to keep it out of ARM deployment logs. {% endhint %} {% endstep %} {% endstepper %} ## How to check it worked All four Microsoft Graph permissions show **Granted** (green checkmark) in the **API permissions** list, and you have copied both the **Application (client) ID** and the **client secret value**. ## Related * [Prerequisites](/getting-started/01-prerequisites) * [Step 2 — Azure Marketplace](/getting-started/03-deploy) * [Entra ID Permissions](/trust-security-and-data-handling/entra-permissions) # Step 2 — Azure Marketplace Deploy With your App Registration complete, you are ready to deploy the AOH Sync VM from the Azure Marketplace. Filling in the form takes a few minutes; Azure then provisions the VM in approximately **2–3 minutes**. {% stepper %} {% step %} **Find AOH Sync in the Marketplace** In the [Azure Portal](https://portal.azure.com), search for **AOH Sync** in the Marketplace and click **Deploy**. {% endstep %} {% step %} **Fill in the deployment form** Complete each field in the Marketplace form: | Field | What to enter | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Virtual Machine Name** | A name for the VM resource (for example, `aoh-sync-vm`) | | **Admin Username** | The SSH user for the VM (note this value — you'll need it for CLI maintenance) | | **VM Size** | **Standard\_D4s\_v3 or larger** recommended for production (Standard\_D8s\_v3 and Standard\_D4s\_v5 also recommended; Standard\_D2s\_v3 is the minimum) | | **OS Disk Type** | **Premium SSD** recommended for production | | **OS Disk Size (GB)** | **64 GB minimum** | | **AOH Sync License Key** | Your license key in the format `CS-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX` | | **Domain (FQDN)** | The fully qualified domain name where AOH Sync will be accessible — for example, `sync.yourcompany.com`. Enter the domain only; do **not** include `https://` | | **Azure AD App Registration — Client ID** | The Application (client) ID from [Step 1 — App Registration](/getting-started/02-app-registration) | | **Networking** | Select the subnet for the VM | {% hint style="warning" %} **Do not enter your client secret here.** The Marketplace form and ARM template log deployment parameters — your secret is collected securely in the browser setup wizard (over TLS) in a later step. Entering it here would expose it in deployment logs. {% endhint %} AOH Sync carries your License Key, Domain, and Client ID from this form directly into the browser setup wizard — you will not need to re-enter them. Click **Review + create**, confirm your settings, then click **Create**. {% endstep %} {% step %} **Wait for provisioning** Azure provisions the VM and writes your initial configuration automatically. This typically takes **2–3 minutes**. You can monitor progress in the Azure Portal under the deployment's **Overview** tab. {% endstep %} {% endstepper %} {% hint style="info" %} Once provisioning completes, note the **Public IP address** of the new VM — you will need it in the next step to create your DNS record. {% endhint %} ## How to check it worked The VM shows a status of **Running** in the Azure Portal, and you can see its **Public IP address** on the VM's **Overview** page. ## Related * [Step 1 — App Registration](/getting-started/02-app-registration) * [Step 3 — DNS](/getting-started/04-dns) # Step 3 — DNS With your VM deployed, point your chosen domain to the VM's public IP address. DNS changes typically propagate within a few minutes, though it can take longer depending on your provider. {% stepper %} {% step %} **Get the VM's public IP address** In the Azure Portal, navigate to the **Public IP resource** that was created with your deployment and copy the IP address. {% endstep %} {% step %} **Add a DNS A record** With your DNS provider, add the following record: | Type | Name | Value | | ---- | --------------------------------- | --------------------------- | | `A` | `sync` (or your chosen subdomain) | Your VM's public IP address | For example, if your domain is `yourcompany.com` and your subdomain is `sync`, the record should point `sync.yourcompany.com` to the VM's IP. {% endstep %} {% step %} **Confirm the record resolves** Before continuing, verify that your domain now points to the VM's IP. From any terminal, run: ``` nslookup ``` The output should show your VM's public IP address. You can also use an online DNS lookup tool if you do not have a terminal available. Once the record resolves correctly, you are ready to continue. {% endstep %} {% endstepper %} {% hint style="info" %} Once DNS resolves, AOH Sync obtains a TLS certificate for your domain automatically. If you prefer to supply your own certificate, you can upload a `.crt`/`.pem` file and private key (or paste PEM) in the browser setup wizard in [Step 4 — First Login](/getting-started/05-first-login). {% endhint %} ## How to check it worked Running `nslookup ` (or an equivalent DNS lookup) returns your VM's public IP address. ## Related * [Step 2 — Azure Marketplace](/getting-started/03-deploy) * [Step 4 — First Login](/getting-started/05-first-login) # Step 4 — First Login With DNS resolving, open the AOH Sync browser setup wizard to complete installation. The wizard takes approximately **10–15 minutes** to run. {% stepper %} {% step %} **Open the setup wizard** In a browser, navigate to: ``` https:///onboard ``` Replace `` with the domain you configured in [Step 3 — DNS](/getting-started/04-dns) — for example, `https://sync.yourcompany.com/onboard`. The wizard pre-fills your **License Key**, **Domain**, and **Client ID** from the values you entered during the Marketplace deployment. You do not need to re-enter them. {% endstep %} {% step %} **Enter your Azure AD credentials** The wizard asks for the following: | Field | Where to find it | | --------------------------------------------- | ------------------------------------------------------------------------------------------------ | | **Azure AD Tenant ID** | Azure Portal → **Microsoft Entra ID** → **Overview** → *Tenant ID* | | **Azure AD App Registration — Client Secret** | The secret value you copied in [Step 1 — App Registration](/getting-started/02-app-registration) | {% hint style="info" %} Your Client Secret is collected here — over TLS in the browser — rather than during the Marketplace deployment. This keeps the secret out of ARM deployment logs. {% endhint %} {% endstep %} {% step %} **Optionally supply a TLS certificate** By default, AOH Sync obtains a TLS certificate automatically once DNS resolves. If you prefer to supply your own certificate, you can: * Upload a `.crt` or `.pem` certificate file and its private key, or * Paste your PEM-encoded certificate and key directly into the wizard If you skip this step, AOH Sync will obtain a certificate automatically — no action required. {% endstep %} {% step %} **Accept the terms and start the install** Review and accept the terms of service, then click **Start install**. The page shows live installation progress. The process takes approximately **10–15 minutes**. Keep the browser tab open during this time. Once installation is complete, AOH Sync is live at `https://`. {% endstep %} {% endstepper %} {% hint style="warning" %} If the install fails or the page does not load, confirm that your DNS record has fully propagated and that the VM is in a **Running** state in the Azure Portal. Contact support at **** if you need assistance. {% endhint %} ## How to check it worked After installation completes, the AOH Sync dashboard loads at `https://` when you open it in a browser. ## Related * [Step 3 — DNS](/getting-started/04-dns) * [Step 5 — Redirect URI](/getting-started/06-redirect-uri) # Step 5 — Redirect URI The final configuration step is to add the OAuth redirect URI to your App Registration. This tells Entra ID where to send users after they authenticate. {% stepper %} {% step %} **Open your App Registration** In the [Azure Portal](https://portal.azure.com), navigate to **Microsoft Entra ID** → **App registrations** and select the registration you created in [Step 1](/getting-started/02-app-registration). {% endstep %} {% step %} **Add the redirect URI** 1. Go to **Authentication** → **Add a platform** → **Web**. 2. Set the redirect URI to: ``` https:///auth/callback ``` Replace `` with the subdomain you configured in [Step 3](/getting-started/04-dns) — for example, `https://sync.yourcompany.com/auth/callback`. 3. Click **Save**. {% endstep %} {% endstepper %} {% hint style="success" %} AOH Sync is now fully configured. Open `https://` in your browser to sign in for the first time. {% endhint %} ## How to check it worked The redirect URI appears in your App Registration's **Authentication** page under **Web** → **Redirect URIs**, and you can sign in to AOH Sync at `https://` without an authentication error. ## Related * [Step 4 — First Login](/getting-started/05-first-login) * [Step 9 — Run Your First Sync](/getting-started/10-first-sync) * [Managing Your Instance](/getting-started/11-managing-your-instance) # Step 6 — Connect a Source System Connect the HR or identity system that AOH Sync reads people from. Adding a Source System automatically creates an Account Import connector for it. (\~5 minutes) {% stepper %} {% step %} **Open Source Systems and add a new source** Navigate to **Source Systems** in the left sidebar. Click **+ Add Source System** and choose the system type from the dropdown. ![Add Source System dialog showing a type-selection dropdown with options including HR platforms, relational databases, file feeds, and LDAP directories](/files/TEzhIylUP5pYm7kQ9NW9) *Available types include HR platforms (Gusto, ADP), relational databases (SQL Server, MySQL, and others), file feeds (CSV upload or CSV over SFTP), and LDAP directories.* {% endstep %} {% step %} **Enter the connection details** After selecting your source type, the form expands with fields specific to that type. Supply the required details: * **HR platforms (Gusto, ADP)** — enter your API credentials. * **Relational databases (SQL Server, MySQL, and others)** — complete the connection form with your host, port, credentials, and database details. * **File feeds (CSV)** — for CSV over SFTP, enter the SFTP host and path; for a direct CSV upload, use the **Download Template** option to get a correctly structured file, then upload it. * **LDAP** — enter the directory server host, bind credentials, and base DN. ![Source System connection form showing the SQL Server example — fields for System Name, Database driver (fixed per type), Database host, Database port, Database username, and Database password](/files/XUp3c2wL3nBnNiYD0aW1) *The connection form shown here is for a SQL Server source. Fields vary by type; CSV types show a Download Template option and a file upload control instead.* {% endstep %} {% step %} **Save and confirm the Account Import connector** Click **Save**. AOH Sync tests the connection and adds the new Source System to the list. At the same time, AOH Sync automatically creates an **Account Import connector** for it — this connector is responsible for bringing Account records from the source into AOH Sync and linking them to Identities by a join key. ![Connectors page showing a newly created Account Import connector for the connected source system](/files/ENbjG2QCgCtXsU3nRXpn) *Each connected Source System gets its own Account Import connector. You can see it on the Connectors page immediately after saving.* {% endstep %} {% endstepper %} ## How to check it worked The new source appears in the **Source Systems** list, and an **Account Import** connector for it appears on the **Connectors** page. ## Related * [Step 7 — Connect a Target System](/getting-started/08-connect-target-system) * [Source Systems](/feature-reference/source-systems) * [Connectors](/feature-reference/connectors) # Step 7 — Connect a Target System Connect the Microsoft Entra ID or Active Directory tenant that AOH Sync provisions identities into. Adding a Target System automatically creates an Identity Ingestion connector that reads your directory's current state. (\~10 minutes) {% stepper %} {% step %} **Open Target Systems and start the wizard** Navigate to **Target Systems** in the left sidebar. Click **+ Add Target System**. The setup wizard opens at **Step 1 of 4**. ![Add Target System wizard Step 1 of 4, showing two selectable cards — Entra ID (cloud-only) and Active Directory (hybrid) — plus a Search Microsoft gallery field and a Provider template dropdown defaulting to Custom SCIM](/files/foRlPVRozFmfPXHIO7xQ) *Step 1 of 4: choose your provisioning topology. Use the Search Microsoft gallery field to find a vendor template (Workday, BambooHR, ServiceNow, and others) if needed. The Provider template defaults to Custom SCIM.* Choose one of the two provisioning topologies: * **Entra ID (cloud-only)** — provision identities directly into Microsoft Entra ID. No on-premises agent is required. Choose this option if your organisation manages identities entirely in the cloud. * **Active Directory (hybrid)** — provision identities into an on-premises Active Directory domain via a provisioning agent. Choose this option if you have an on-premises AD environment that must remain the authoritative directory. Optionally use the **Search Microsoft gallery** field to find a vendor provider template, or leave **Provider template** at the default **Custom SCIM** for generic API-driven inbound provisioning. Click **Next** when ready. {% endstep %} {% step %} **Complete the Azure setup checklist** **Step 2 of 4** shows the Azure setup checklist. Work through each item in the Azure Portal before continuing: 1. Create an **Enterprise Application** in your Entra ID tenant for AOH Sync provisioning. 2. In the Enterprise Application, open **Provisioning** and set **Provisioning Mode** to **Automatic**. 3. Under **Admin Credentials**, create a **Client Secret** for AOH Sync to authenticate. 4. Grant the following Microsoft Graph permissions to the Enterprise Application (these are provisioning permissions, separate from the sign-in App Registration you created in Step 1 of Getting Started): | Permission | Purpose | | --------------------------------- | --------------------------------- | | `AuditLog.Read.All` | Read audit log entries | | `Directory.Read.All` | Read directory data | | `Group.ReadWrite.All` | Manage group memberships | | `Synchronization.ReadWrite.All` | Manage provisioning configuration | | `SynchronizationData-User.Upload` | Upload user provisioning data | | `User.Read.All` | Read all user profiles | | `User.ReadWrite.All` | Create and update user accounts | ![Add Target System wizard Step 2 of 4 showing the Azure setup checklist with numbered items for creating an Enterprise Application, configuring Inbound Provisioning, creating a Client Secret, and granting Microsoft Graph permissions](/files/HMQZftWPA1647TAgE9up) *The wizard provides a Full Microsoft guide link for detailed Azure Portal instructions at each checklist item.* {% endstep %} {% step %} **Enter the Enterprise Application credentials** **Step 3 of 4**: enter the credentials from the Enterprise Application you just configured, then click **Add Target System**. ![Add Target System wizard Step 3 of 4 showing credential fields — Display Name, Tenant ID, Client ID, Client Secret, Region, and optional Sync Schedule](/files/ETdvMvl8tnCnLJv53h43) *Enter the Display Name, Tenant ID, Client ID, and Client Secret from your Enterprise Application. Optionally set a Region and a Sync Schedule.* | Field | Where to find it | | ----------------- | ---------------------------------------------------------------- | | **Display Name** | A friendly name for this target in AOH Sync | | **Tenant ID** | Your Entra ID tenant's Directory (tenant) ID in the Azure Portal | | **Client ID** | The Application (client) ID of the Enterprise Application | | **Client Secret** | The client secret value you created in step 2 | | **Region** | The Azure region your tenant is homed in | | **Sync Schedule** | Optional — you can also configure this later on the connector | | {% endstep %} | | {% step %} **Confirm the Identity Ingestion connector** After saving, the Target System appears in the **Target Systems** list. AOH Sync also automatically creates an **Identity Ingestion connector** for it — this connector reads your directory's current state so AOH Sync can match incoming Accounts against existing directory records before provisioning. {% endstep %} {% endstepper %} ## How to check it worked The new target appears in the **Target Systems** list, and an **Identity Ingestion** connector for it appears on the **Connectors** page. ## Related * [Step 8 — Set Up Provisioning](/getting-started/09-set-up-provisioning) * [Target Systems](/feature-reference/target-systems) * [Microsoft Entra Permissions Requested](/trust-security-and-data-handling/entra-permissions) # Step 8 — Set Up Provisioning Create the Outbound Provisioning connector — the connector that writes identities and accounts out to your Entra ID or Active Directory target. This is the core of what AOH Sync does. Unlike the Account Import and Identity Ingestion connectors (created automatically when you add a Source or Target System), you create this connector deliberately. (\~5 minutes) {% stepper %} {% step %} **Open Connectors and review the categories** Navigate to **Connectors** in the left sidebar. The page shows three connector categories: * **Identity Ingestion** — auto-created when you added your Target System; reads your directory's current state. * **Account Import** — auto-created when you added your Source System; brings Account records into AOH Sync. * **Outbound Provisioning** — what you are about to create; writes identities and accounts out to your target directory. ![Connectors page showing the three connector categories — Identity Ingestion, Account Import, and Outbound Provisioning — with auto-created connectors already listed in the first two categories](/files/HZruaSEcpoYTym1YG1Bt) *The Connectors page after completing Steps 6 and 7. Identity Ingestion and Account Import connectors are already present. Outbound Provisioning is empty until you create one.* Click **+ New Connector** to open the creation wizard. {% endstep %} {% step %} **Step 1 of 4 — Choose your Source System** Select the Source System this connector should read Account data from. ![New Connector wizard Step 1 of 4 showing a list of available Source Systems to choose from](/files/GenHClc6kpSV2gI1TSTk) *Choose the Source System you connected in Step 6.* {% endstep %} {% step %} **Step 2 of 4 — Choose your Target System** Select the Target System this connector should provision identities into. ![New Connector wizard Step 2 of 4 showing a list of available Target Systems to choose from](/files/SxyC4fWSKnfhErSDq6eT) *Choose the Target System you connected in Step 7.* {% endstep %} {% step %} **Step 3 of 4 — Confirm connector details** Review and confirm the connector name and settings. The **Display Name** is auto-filled based on your source and target selection. The identity mode is set automatically from the target you chose. The identity-matching key is configured per attribute in the mapping editor after the connector is created. If you selected an Active Directory target, you can optionally set a **Target OU Distinguished Name** to control which organisational unit provisioned accounts land in. ![New Connector wizard Step 3 of 4 showing the Display Name field (auto-filled) and an optional Target OU Distinguished Name field for Active Directory targets](/files/A8Gh1sL04G0c7im7P3hd) *The Display Name is auto-filled. For Active Directory targets, set the Target OU Distinguished Name if you want provisioned accounts in a specific OU.* {% endstep %} {% step %} **Step 4 of 4 — Set a schedule and create** Optionally choose a **Sync Schedule** from the preset options, then review the summary and click **Create Connector**. | Schedule option | When the connector runs | | ----------------- | ---------------------------------- | | Every 15 min | Continuously throughout the day | | Every hour | Once per hour | | Daily 9 AM UTC | Once per day at 9 AM UTC | | Weekdays 8 AM UTC | Monday through Friday at 8 AM UTC | | On-demand only | Only when you trigger a manual run | ![New Connector wizard Step 4 of 4 showing the Sync Schedule dropdown with preset options and a Create Connector button](/files/UMx0F3YMaA63bolZTpoq) *Choose a schedule, review the summary, and click Create Connector. You can change the schedule at any time from the connector's Schedule tab.* {% endstep %} {% endstepper %} ## How to check it worked The new connector appears under **Outbound Provisioning** on the **Connectors** page. ## Related * [Step 9 — Run Your First Sync](/getting-started/10-first-sync) * [Connectors](/feature-reference/connectors) * [Schedule](/feature-reference/connectors/schedule) # Step 9 — Run Your First Sync After deploying AOH Sync and completing system setup, this guide walks you through triggering your first sync and verifying the results. {% hint style="info" %} Before starting this guide, confirm your source, target, and provisioning Connector are set up — covered in [Step 6 — Connect a Source System](/getting-started/07-connect-source-system), [Step 7 — Connect a Target System](/getting-started/08-connect-target-system), and [Step 8 — Set Up Provisioning](/getting-started/09-set-up-provisioning). {% endhint %} {% stepper %} {% step %} **Confirm your Connector's Field Mappings** Open **Connectors** in the left sidebar and select the Connector that links your Source System to your Target System. Navigate to the [**Field Mappings**](/feature-reference/connectors/field-mappings) tab. Review each mapping to make sure source fields are mapped to the correct target attributes. Pay particular attention to the fields that drive identity matching — typically a unique identifier such as an employee ID or email address. Incorrect mappings here will cause data to land in the wrong attributes or prevent records from being matched on subsequent syncs. Make any needed adjustments, then save your changes. AOH Sync records each change in [Revisions & History](/feature-reference/connectors/revisions), giving you an audit trail of every mapping change. {% endstep %} {% step %} **Set a Schedule or use Run Now** Navigate to the [**Schedule**](/feature-reference/connectors/schedule) tab on the same Connector. * To run the sync immediately without waiting for a scheduled window, use the **Run Now** option on the Connector. This is the fastest way to validate your configuration. * To set a recurring sync cadence, configure your schedule here. AOH Sync will run the Connector automatically at the interval you specify. {% hint style="info" %} For your first sync, using Run Now lets you see results quickly and catch any mapping or connection issues before committing to a schedule. {% endhint %} {% endstep %} {% step %} **Watch progress in Sync History** After triggering the sync, go to the [**Sync History**](/feature-reference/connectors/logs) tab on the Connector. The log updates as the sync runs and shows each record processed, the action taken (created, updated, skipped, or errored), and any warnings. If errors appear, expand the affected rows for details. Common causes include: * A source field mapped to a required target attribute that is empty or missing for some records. * A connection interruption to the Source System or Target System. * A field type mismatch between the source value and the expected target format. Address any errors, then re-run if needed. {% endstep %} {% step %} **Verify results on the Dashboard and in Browsing Identities** Once the sync log shows completion, verify the results in two places: 1. [**Dashboard**](/feature-reference/dashboard) — Check the summary metrics to confirm the expected number of Identities and Accounts are reflected. The Dashboard updates after each sync run. 2. [**Browsing Identities**](/feature-reference/browsing-identities) — Browse the Identities list to spot-check a few records. Confirm that the attributes from your Source System are present and correctly populated on each Identity's detail view. If the counts or attribute values look wrong, return to [Field Mappings](/feature-reference/connectors/field-mappings) and adjust, then run again. {% endstep %} {% endstepper %} ## Related * [Source Systems](/feature-reference/source-systems) * [Target Systems](/feature-reference/target-systems) * [Connectors](/feature-reference/connectors) * [Field Mappings](/feature-reference/connectors/field-mappings) * [Schedule](/feature-reference/connectors/schedule) * [Sync History](/feature-reference/connectors/logs) * [Dashboard](/feature-reference/dashboard) * [Browsing Identities](/feature-reference/browsing-identities) # Managing Your Instance Once AOH Sync is installed, you can manage its status, apply updates, and restart AOH Sync if needed — both from the command line and from within the AOH Sync dashboard. ## Command-line management Every SSH session to your VM opens with a status message confirming AOH Sync is installed. To check status, view logs, restart AOH Sync if needed, or apply updates from the command line, run: ``` sudo cloudsync-maintenance ``` ## Dashboard — System Settings AOH Sync also exposes instance management through **System Settings** in the dashboard. Navigate to **System Settings** in the left sidebar to access the **Update status** page. ![AOH Sync Update status page showing an available version (1.2.12) with a stable channel tag, and an Apply update button](/files/anjV8VIbnQGjkda8N38Z) *The Update status page shows your installed version, the latest available version on the stable channel, and the control to apply the update.* From this page you can: | Action | What it does | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **View current and available version** | See your installed version alongside the latest available release and its channel tag (for example, stable) | | **Apply update** | Rolls out the latest AOH Sync release to your instance. The session reconnects automatically once the update is complete. | {% hint style="info" %} You can also monitor overall sync health from the dashboard's **Status & Logs** page in the sidebar. {% endhint %} ## Related * [Step 5 — Redirect URI](/getting-started/06-redirect-uri) * [Getting Started overview](https://github.com/AOHWV/docs/tree/main/getting-started/README.md) * [System Settings](/administration/system-settings) # 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 | Page | What it explains | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | [How AOH Sync Works](/core-concepts/how-aohsync-works) | The end-to-end flow from your Source Systems to Microsoft Entra ID | | [Identities, Accounts & Users](/core-concepts/identities-accounts-users) | How AOH Sync models a person across multiple source systems | | [Source & Target Systems](/core-concepts/source-and-target-systems) | What Source Systems and Target Systems are, and how they differ | | [Sync Types](/core-concepts/sync-types) | Full, incremental, and delta syncs — when each runs and what it does | | [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) | Joiner, Mover, Leaver, and Reactivation events — how AOH Sync tracks workforce changes | | [Roles & Permissions](/core-concepts/roles-and-permissions) | Who can do what inside AOH Sync, and how access decisions are enforced | | [Machine Identities](/core-concepts/machine-identities) | Non-human accounts — service accounts, shared mailboxes, and bots — and how AOH Sync tracks them | ## Related * [Getting Started](/getting-started/getting-started) * [Feature Reference](/feature-reference/dashboard) # How AOH Sync Works AOH Sync reads identity data from your connected Source Systems, builds a normalized view of your workforce, and continuously keeps Microsoft Entra ID in sync — without manual intervention. ## The three-stage flow Every sync follows the same path: ``` Source Systems ──► AOH Sync ──► Microsoft Entra ID (HR, directory, (reads, (provisions, REST, CSV) resolves, updates, enriches) deprovisions) ``` **Stage 1 — Ingest.** AOH Sync reads data from each connected Source System via a Connector. Connectors support HR platforms, database-backed systems, API-connected systems, and CSV or SFTP file feeds. Each Connector runs on a configurable schedule (or on demand) and fetches only the records that have changed since the last run. **Stage 2 — Resolve.** Incoming records from all your sources are merged into a single, normalized Identity for each real person. If the same person exists in both your HR system and a secondary directory, AOH Sync matches them by a configurable join key and combines their attributes into one Identity. When two sources supply the same attribute, a priority order you control decides which value wins. **Stage 3 — Provision.** AOH Sync compares each Identity's current state against what Entra ID holds. It creates, updates, or disables Entra accounts to match — using only the permissions you granted during setup. No data is written to Entra that wasn't first reviewed through your attribute mappings. {% hint style="info" %} Your identity data never leaves your own Azure environment — AOH Sync runs entirely inside your subscription and does not send your identity data to any external service. {% endhint %} ## Sync vs. provisioning These two terms describe different directions of data movement: * **Sync** pulls data *in*. AOH Sync reads from your Source and Target Systems and updates its Identity graph to reflect reality. For Entra ID, this uses delta queries so only changes come over. * **Provisioning** pushes data *out*. AOH Sync writes the resolved Identity picture to a Target System so that access matches intent. Both can run on a schedule or be triggered manually. ## What triggers a sync | Trigger | When it runs | | ------------------- | ----------------------------------------------------------------------------------------------------------- | | Scheduled full sync | On the schedule you configure per Connector | | Incremental sync | After a full sync, picks up changes since the last run | | Delta sync | Near-real-time; detects only the specific attributes that changed within a record — the most efficient mode | | Manual trigger | On demand from the Connectors screen or via the API | For a deeper explanation of each sync mode, see [Sync Types](/core-concepts/sync-types). ## Long-running work Full syncs and provisioning runs operate in the background. The interface returns immediately when you trigger one; you can track progress and results from the Connectors sync history or the Status & Logs screen. ## Related * [Source & Target Systems](/core-concepts/source-and-target-systems) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Sync Types](/core-concepts/sync-types) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) * [What is AOH Sync?](/readme/what-is-aohsync) # Identities, Accounts & Users An **Identity** is AOH Sync's unified record for a single real person — regardless of how many systems they appear in. ## Why identities exist Most organizations have the same person spread across multiple systems: an HR record in a payroll system, a profile in Active Directory, and perhaps an entry in a contractor portal. Without a normalized view, you have no single answer to "who is this person, and what should their Entra account look like?" AOH Sync solves this by creating one Identity per person and linking every system record to it. You see one canonical view of each person; AOH Sync resolves conflicts between sources automatically. ![The Identities screen showing canonical identity records across all connected systems, with columns for Name, Status, Email, Title, Sources, Accounts, and Last Updated](/files/8FjuTVm1Jp5ADx0KMfeL) *Each row in the Identities screen is a single Identity. The Sources and Accounts columns show how many systems contributed data to that person.* ## Users vs. Accounts Not every record attached to an Identity is the same kind of thing. AOH Sync distinguishes two: | | User | Account | | -------------- | ------------------------ | -------------------------------------- | | **Comes from** | Target system (Entra ID) | Source system (HR, payroll, SaaS, CSV) | | **Can log in** | Yes | No | | **Role** | Controls access | Provides attributes | | **Linked to** | One Identity | One Identity | A **User** is an authentication-capable record from a target system such as Entra ID — it is what a person logs in with and what controls SSO and downstream access. An **Account** is a data record from a source system (an HR row, a payroll record) that describes a person but cannot log in. Both link back to exactly one Identity. ## What an Identity contains An Identity aggregates four types of information: | Component | What it is | | ---------------------- | ------------------------------------------------------------------------------------------- | | **Users** | The person's login-capable records in your Target Systems — controls access | | **Accounts** | Data records from your Source Systems — provides attributes | | **Machine Identities** | Non-human accounts (service accounts, shared mailboxes, bots) associated with this Identity | | **Attributes** | Individual data fields (name, job title, department, etc.) drawn from one or more sources | Every Identity carries a **status** — derived from its linked records, not set by hand. A person whose only login account is disabled is not active just because a stale source record lists them as current. ## How records attach (join keys) AOH Sync matches incoming users and accounts to an Identity using configurable **join keys** — shared values such as a user principal name or employee ID. When multiple keys could match, a priority order decides which one wins. A record that matches nothing becomes an [Orphaned Account](/feature-reference/orphaned-accounts) and surfaces for review. ## How attributes are resolved When the same attribute (for example, job title) arrives from two different sources, AOH Sync applies a **priority** to decide which value to use. You set the priority order for each Connector in your attribute mapping configuration. The source with the highest priority for that field wins; lower-priority sources fill in any fields the higher-priority source did not supply. Each attribute record tracks: * **Which source supplied it** — so you can trace every value back to its origin. * **When it was last updated** — so you can see how fresh the data is. * **Its priority** — the rank used to resolve conflicts with other sources. {% hint style="info" %} You can override the default priority on a per-attribute basis in your Connector's Field Mappings. This lets you, for example, trust your HR system for legal name but your directory for email address. {% endhint %} ## Machine Identities A **Machine Identity** is a non-human account — a service account, a shared mailbox, an integration bot — that is associated with an Identity for accountability purposes. Machine Identities carry a classification, an owner, and a risk score so your security team can track them alongside human identities. ## Related * [Source & Target Systems](/core-concepts/source-and-target-systems) * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Machine Identities](/core-concepts/machine-identities) * [Browsing Identities](/feature-reference/browsing-identities/identities) * [Field Mappings](/feature-reference/connectors/field-mappings) # Machine Identities A **Machine Identity** is a non-human account — such as a service account, shared mailbox, automation user, or application identity — that AOH Sync tracks alongside your human Identities. ## Why Machine Identities matter In most environments, non-human accounts outnumber human ones and are frequently overlooked by identity governance processes. A service account with excessive permissions or no assigned owner is a common security gap. AOH Sync surfaces these accounts explicitly so your team can assess their risk, assign ownership, and keep them in scope for your identity program. The key question for a Machine Identity is different from the one you ask for a person: instead of "should this person still have access?", you ask "who is responsible for this account — and what happens to it when that person leaves?" ## How Machine Identities relate to Identities and Accounts Every account record pulled from a Source System starts as an **Account**. When an Account is identified as non-human — either by your [Machine Identity Rules](/feature-reference/connectors/machine-identity-rules) or by a manual flag from the [Accounts screen](/feature-reference/browsing-identities/accounts) — AOH Sync reclassifies it as a Machine Identity. Machine Identities can be linked to a human **Identity** as the responsible owner. This creates an accountability chain: you know who is responsible for each service account, even if the account itself has no human user. | Concept | What it is | | -------------------- | -------------------------------------------------------------------------------------------------- | | **Account** | A raw account record from a Source System. May belong to a human or a non-human. | | **Identity** | AOH Sync's unified record for a single real person, aggregating accounts from multiple sources. | | **Machine Identity** | A non-human Account that has been classified separately, with its own risk score, type, and owner. | ## Ownership and inheritors Every Machine Identity has an **owner** — a human Identity accountable for it. AOH Sync can also track **inheritors**: the people who would take ownership next if the current owner is unavailable. This makes the accountability chain visible before any transfer is needed. When an owner goes through a [Leaver event](/core-concepts/provisioning-lifecycle), AOH Sync runs an ownership transfer: the Machine Identity is identified, ownership moves to the next party in the chain (typically a manager fallback), and the transfer is recorded in the audit trail. A Machine Identity is never left without accountability. ## Detection AOH Sync identifies Machine Identities using configurable rules defined per Connector — naming patterns, account types, and source-system flags. Rules are per Connector, so a service account in one system can be detected differently than in another. ## Risk scores and classification Each Machine Identity carries a **risk score** between 0 and 1, displayed with a color-coded bar. AOH Sync assigns a **type** to each Machine Identity — such as application, automation, service account, or system — based on how it was classified. ## Related * [Machine Identities (feature screen)](/feature-reference/browsing-identities/machine-identities) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Machine Identity Rules](/feature-reference/connectors/machine-identity-rules) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) # Source & Target Systems AOH Sync has two distinct types of systems: **Source Systems**, which supply identity data, and **Target Systems**, which receive it. ## Source Systems A **Source System** is any system that holds authoritative identity data for your organization — typically an HR platform, a database-backed system, an API-connected system, or a flat-file feed. AOH Sync reads from your Source Systems via **Connectors**. Each Connector is configured with the credentials, schedule, and field mappings needed to pull records from that source. You can connect multiple Source Systems simultaneously; AOH Sync merges the data they provide into a single normalized Identity for each person. Supported source types include: * HR platforms and payroll systems (via API or CSV/SFTP export) * Database-backed HR and directory systems * API-connected systems * CSV and SFTP file feeds You manage your Source Systems from the **Source Systems** screen under Configuration. {% hint style="info" %} AOH Sync never writes back to your Source Systems. It is read-only against every source you connect. {% endhint %} ## Target Systems A **Target System** is where AOH Sync provisions and manages accounts. Currently, AOH Sync provisions to **Microsoft Entra ID** (formerly Azure Active Directory). Each Target System you configure represents one Entra ID tenant. AOH Sync uses a service principal — a non-interactive application identity you register in your Entra tenant during setup — to create, update, and disable user accounts on your behalf. Within a Target System, AOH Sync can manage: | Area | What AOH Sync does | | ---------------- | ---------------------------------------------------------------------- | | **Directory** | Creates and updates user accounts; disables accounts on deprovisioning | | **Applications** | Assigns or removes application access based on group membership | | **Compliance** | Reports on account state against your configured compliance posture | | **Security** | Tracks sign-in risk, account status, and policy coverage | | **Helpdesk** | Surfaces identity and account detail for support workflows | You manage your Target Systems from the **Target Systems** screen under Configuration. ## How they work together ``` Source System A ──┐ Source System B ──┼──► AOH Sync ──► Target System (Entra ID tenant) Source System C ──┘ ``` AOH Sync reads from all your Source Systems on each sync cycle, resolves any conflicts between them, and writes the authoritative result to your Target System. The Source Systems own the data; the Target System reflects it. ## Related * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Connectors](/feature-reference/connectors) * [Source Systems](/feature-reference/source-systems) * [Target Systems (Entra)](/feature-reference/target-systems) # Sync Types AOH Sync uses three sync modes — full, incremental, and delta — each suited to a different point in the sync cycle. ## Full sync A **full sync** reads every record from a Source System from scratch. AOH Sync fetches the complete dataset, rebuilds the Identity model, and reconciles the result with your Target System. Full syncs are the most thorough but also the most resource-intensive. They are typically run: * When you first connect a new Source System or Target System. * After a configuration change (such as new field mappings or a new Connector). * On a scheduled cadence you define (for example, nightly or weekly). {% hint style="info" %} A full sync is not the same as a "destructive" reset. AOH Sync compares what it finds against what already exists and only applies the changes needed — it does not blindly recreate accounts. {% endhint %} ## Incremental sync An **incremental sync** picks up only the records that have changed since the last successful sync run. It uses the timestamp of the previous run as a watermark and fetches forward from there. Incremental syncs run faster than full syncs and are the default mode for scheduled cycles after the initial full sync. They are suited for keeping your Target System continuously up to date without the overhead of a full re-read. ## Delta sync A **delta sync** goes one step further: it detects only the specific fields that changed within a record, not just the records themselves. This makes delta syncs the most efficient mode and the one best suited for near-real-time propagation of changes. Delta syncs are used when your Source System supports change-tracking or delta query feeds. When a delta is available, AOH Sync processes the exact set of changed attributes — reducing both sync time and the number of writes to your Target System. ## Comparison | Mode | What it reads | When to use | | --------------- | ---------------------------------- | ----------------------------------------------------------------------- | | **Full** | All records from the source | Initial load; post-configuration changes; scheduled deep reconciliation | | **Incremental** | Records changed since the last run | Routine scheduled syncs | | **Delta** | Only the attributes that changed | Near-real-time updates when the source supports change tracking | ## SCIM bulk provisioning For Target Systems that support it, AOH Sync uses **SCIM** (System for Cross-domain Identity Management) to push users and groups in bulk. AOH Sync assembles the SCIM bulk requests from your Connector's attribute mappings and sends them to the Target System in a single operation. SCIM runs as part of provisioning rather than as a named sync mode. ## Triggers Every sync mode can be started in two ways: * **Scheduled** — on the schedule you set on the Connector's Schedule tab. * **Manual** — from the Connectors screen or via the [Public API](/developer-and-api/developer-api). For details on configuring schedules, see [Scheduling & Orchestration](/feature-reference/scheduling-orchestration). ## Related * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Connectors](/feature-reference/connectors) * [Scheduling & Orchestration](/feature-reference/scheduling-orchestration) * [Sync History](/feature-reference/connectors/logs) # Provisioning & Deprovisioning Lifecycle AOH Sync tracks four lifecycle events — **Joiner**, **Mover**, **Leaver**, and **Reactivation** — that together cover every significant change to a person's relationship with your organization. {% hint style="info" %} Lifecycle events are tracked at the Identity level, not per individual account. When a change comes from one source record, the event is still recorded against the person — not against that record alone. {% endhint %} ## The four events ### Joiner A **Joiner** event occurs when a new Identity appears in your Source Systems for the first time. AOH Sync detects the new record, creates the corresponding Identity, and provisions an account in Microsoft Entra ID according to your configured attribute mappings and group assignments. Typical result: a new Entra account is created and the user can sign in. ### Mover A **Mover** event occurs when an existing Identity's attributes change in a meaningful way — a department transfer, a title change, a change in reporting structure. AOH Sync detects the difference between the current state and the previous state, updates the Entra account accordingly, and adjusts group memberships or application access if your mappings are configured to respond to those changes. Typical result: the existing Entra account is updated; access reflects the person's new role. {% hint style="info" %} Mover events are where excess access tends to accumulate: new access is granted for the new role, but access from the old role may not be removed unless your mappings are configured to do so. Review your attribute mappings and group assignment rules to ensure old access is cleaned up on role changes. {% endhint %} ### Leaver A **Leaver** event occurs when all of an Identity's login-capable accounts become disabled or are staged for disablement — typically because the person has left the organization. AOH Sync disables or removes the corresponding Entra account based on your deprovisioning policy. Typical result: the Entra account is disabled, revoking sign-in access. {% hint style="warning" %} AOH Sync disables Entra accounts on Leaver events by default. Permanent deletion depends on your configured deprovisioning policy. Review your policy before go-live to avoid accidental data loss. {% endhint %} ### Reactivation A **Reactivation** event occurs when a previously inactive Identity becomes active again — for example, a returning employee or contractor. This is distinct from a new Joiner: the person's history remains intact, and any access that was previously attached may still need to be reviewed before it is restored. ## The full lifecycle in order ``` New record in source ──► Joiner ──► Entra account created Attribute change in source ──► Mover ──► Entra account updated All login accounts disabled ──► Leaver ──► Entra account disabled Previously inactive, now active ──► Reactivation ──► Access reviewed and restored ``` ## Why transitions, not just snapshots AOH Sync records the transitions — not only the current state — so that you always have a clear answer to accountability questions. "This person left on this date and these accounts were still active" is only answerable if the leaving was recorded as an event. Lifecycle events feed the audit trail and ensure you can demonstrate a complete, auditable picture of every person's access history. ## Where to see lifecycle events You can review lifecycle history for any Identity from the **Identities** screen — open an Identity record and view its event timeline. The **Sync History** tab on each Connector shows the Joiner, Mover, and Leaver events triggered by that Connector's most recent runs. Lifecycle events are also surfaced in the **Status & Logs** section under Administration. ## Related * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Browsing Identities](/feature-reference/browsing-identities/identities) * [Sync History](/feature-reference/connectors/logs) * [Audit & Status Logs](/administration/audit-and-status-logs) # Roles & Permissions AOH Sync uses role-based access control to determine what each user can see and do. Permissions are granted through **permission groups** — named sets of roles that you assign to users. ## How access decisions work Every permission check in AOH Sync is made on the server, on every request — the interface reflects what the backend permits, and never grants access on its own. This means: * If your access is revoked, the next request is denied immediately. There is no window where the UI still shows a permitted action after the backend has revoked it. * You cannot gain access by navigating directly to a URL or manipulating the interface; the backend is always the authority. * When your group membership changes, the change takes effect on the next request — no sign-out or cache-clear needed. If someone has access they should not, the fix is in the permission group model — in one place — and takes effect immediately. ## Built-in permission groups AOH Sync ships with five system-defined permission groups. You can view and manage them from the **Access Management** screen under Administration. | Group | What it grants | | ------------------------ | --------------------------------------------------------------------------------- | | **Global Administrator** | Unrestricted access to all system features and administration | | **System Administrator** | System operations including configuration, Connectors, scheduling, and monitoring | | **Analyst** | Read-only access to dashboards, lifecycle data, and provisioning status | | **Enterprise Resources** | HR-facing access to Connectors, user lifecycle, and attribute information | | **Security** | Audit logs, secrets management, user lock/unlock, and service monitoring | ![The Access Management screen showing five system permission groups — Analyst, Enterprise Resources, Global Administrator, Security, and System Administrator — with their descriptions and role counts. The Analyst role matrix is expanded below, showing 6 of 22 system roles granted.](/files/vobaOPDdLZuEP2YD4UVN) *The Access Management screen. Each group row shows the number of granular roles it includes. Expand a group to see its full role matrix.* ## Granular roles Each permission group is made up of individual system roles. There are 22 system roles in total, covering areas such as: * Dashboard access and reports generation * Connector management and schedule management * Provisioning status and Entra log access * Attribute information and user lifecycle access * User management and user lock/unlock * Secrets management and Vault administration * Audit log access and service monitoring The full role matrix for any group is visible on the Access Management screen by selecting the group and clicking **View full matrix**. {% hint style="info" %} System permission groups cannot be deleted. You can create custom groups with any combination of the 22 system roles to match your organization's access model. {% endhint %} ## Assigning users to groups User-to-group assignments are managed from the **User Management** screen under Administration. A user can belong to multiple permission groups; their effective permissions are the union of all roles granted by every group they belong to. {% hint style="info" %} Every permission change is recorded in the audit trail — including who made the change, what was modified, and when it took effect. {% endhint %} ## Related * [Access Management](/administration/access-management) * [User Management](/administration/user-management) * [Audit & Status Logs](/administration/audit-and-status-logs) # Dashboard The Dashboard gives you a real-time summary of your identity landscape — total counts, distributions, and trends — across all connected systems. ## Where this data comes from Dashboard metrics are assembled from the Identity and Account data AOH Sync has synced from your connected Source Systems and Target Systems. The counts and charts update after each Sync. ![AOH Sync Dashboard showing the Overview tab with Key Metrics, Department Distribution, Role Distribution charts, and a Trends & Groups panel with Top Groups by Membership](/files/0Q8j0YVuqxbQDWWOl3Te) *The Overview tab displays Total Identities (1,531), Total Groups (106), and Departments (21), with bar charts for Department Distribution and Role Distribution, plus a Trends & Groups section showing the top groups by membership count.* ## What you can do here | Action | What it does | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Click **Overview** | Shows headline counts (Total Identities, Total Groups, Departments), bar charts for Department Distribution and Role Distribution, and the Trends & Groups panel. | | Click **Identity & Security** | Surfaces identity and security posture metrics for your connected environment. | | Click **Accounts** | Breaks down Account counts across your connected Source Systems. | | Click **Machine Identities** | Shows a summary of non-human accounts AOH Sync has identified across your environment. | | Click **Access Overview** | Shows who has access to what, summarized across Target Systems. | | Review **Trends & Groups / Top Groups by Membership** | Lists the groups with the highest membership counts, each tagged with a size tier (High, Medium, or Low), so you can spot unusually large or fast-growing groups at a glance. | ## How to read the Dashboard The Dashboard is your at-a-glance view of your entire identity estate — every person, account, group, and department AOH Sync has discovered across your connected systems. Its guiding idea: **every number is a starting point for an action, not just a statistic.** When a count looks wrong, too high, or too low, the Dashboard is where you notice it — and each metric links you to the place where you can act on it. ### What each tab is for | Tab | Purpose | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Overview** | Headline counts (Total Identities, Total Groups, Departments), bar charts for Department Distribution and Role Distribution, and the Trends & Groups panel. Start here every time you open the Dashboard. | | **Identity & Security** | Identity and security posture metrics for your connected environment. | | **Accounts** | Account counts broken down across your connected Source Systems. | | **Machine Identities** | A summary of non-human accounts AOH Sync has identified across your environment. | | **Access Overview** | A cross-system view of who has access to what, summarized across your Target Systems. | ### From a number to an action {% hint style="info" %} Numbers on the Overview tab are not read-only. Use them to navigate directly to the area that needs attention. {% endhint %} | Metric | What to look for | Where to go next | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | | **Total Identities** | A count that seems higher or lower than expected may indicate orphaned or missing Identities. | Open [Browsing Identities](/feature-reference/browsing-identities) to investigate. | | **Total Groups** | An unexpectedly high group count can signal sprawl or duplicate groups. | Review groups in [Access Management](/administration/access-management) to consolidate. | | **Departments** | Fewer departments than expected may mean your Source Systems are not all connected. | Check your Source Systems configuration. | | **Department Distribution** | A department with a disproportionately large or small bar may reflect a data gap or a coverage blind spot. | Drill into that department's Identities to verify coverage. | | **Role Distribution** | Roles with very high counts warrant a least-privilege review. | Use the Access Overview tab to assess what those roles can reach. | | **Top Groups by Membership** | Groups tagged **High** (like M365 – All Hands at 1,284 members) grant access at scale — any change affects a large population. | Review membership and permissions for High-tier groups first. | ### Reading the Action Center badge The left navigation shows a live count next to **Action Center** (for example, 65 in the screenshot above). This number is the total of open items — stale accounts, unresolved conflicts, policy violations — waiting for your review. If this count is growing, open the Action Center before exploring other tabs. ## Related * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Browsing Identities](/feature-reference/browsing-identities) * [Reports](/feature-reference/reports) # Connectors The Connectors page is your central view of every active data bridge between AOH Sync and your Source and Target Systems. ![The Connectors list showing Identity Ingestion and Account Import groups, with the AOH Test AD connector card displaying sync progress](/files/agbZdOdmeeZeKb7zy4S6) *The Connectors list groups your Connectors by type and surfaces live sync progress for each one.* ## What you can do here | Action | What it does | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Filter by status (All, Active, Stopped, Error) | Narrows the list to Connectors in a specific state so you can quickly spot problems. | | Search Connectors | Finds a specific Connector by name using the search field in the top-right corner. | | Run Now | Triggers an immediate Sync for the selected Connector without waiting for the next scheduled run. | | Logs | Opens the Sync History view for the selected Connector, showing recent run results. | | Mappings | Opens the Field Mappings tab for the selected Connector. | | Click a Connector card | Opens the full Connector detail view with tabs for Overview, Mappings, MI Rules, Revisions, Schedule, and Settings. | ## Understanding the Connectors list Connectors are grouped by type: * **Identity Ingestion** — Connectors that pull Identities and Accounts into AOH Sync from your Target Systems (such as Entra ID or Active Directory). AOH Sync creates these automatically when you add a Target System. * **Account Import** — Connectors that pull Accounts from your Source Systems into AOH Sync, linking them to existing Identities via the Connector's join key. AOH Sync creates these automatically when you add a Source System. Each Connector card shows its current status (Running, Stopped, or Error), the time of its last Sync, the name of its Source System, and a live progress indicator when a Sync is actively running. ## Related * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Source & Target Systems](/core-concepts/source-and-target-systems) * [Sync Types](/core-concepts/sync-types) * [Connector Overview](/feature-reference/connectors/overview) * [Field Mappings](/feature-reference/connectors/field-mappings) * [Schedule](/feature-reference/connectors/schedule) # Overview The Overview tab gives you a real-time snapshot of your Connector's configuration, sync health, and mapping status — all in one place. ![The Connector Overview tab for AOH Test AD → CloudSync (Delta), showing status, mode, pipeline diagram, mapping summary, and recent activity](/files/EbgD3mHX6bsN9Tcjuhha) *The Overview tab summarizes your Connector's current state and the data pipeline from source to target.* ## What you can do here | Action | What it does | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | View status badge (IDLE / RUNNING) | Shows whether the Connector is currently performing a Sync. | | View unpublished changes badge | Alerts you when field mapping changes have been saved but not yet published to the active Sync. | | Expand Live Azure State | Shows a live read of the Connector's state in your connected Azure environment. | | Navigate tabs (Mappings, MI Rules, Revisions, Schedule, Settings) | Moves to the respective configuration view for this Connector. | | Review Mapping Summary | Shows how many Source Field Mappings and Provisioning Mappings are configured, and which target actions (Create, Update, Delete) are enabled. | | Review Pipeline diagram | Confirms that your data source, the Mappings layer, and the Target System are all connected and reporting the expected record counts. | | View Recent Activity | Lists the most recent Sync runs for this Connector. | | Bulk Upload | Replays every source row through the selected mapping revision against the target — use this after a major mapping change to backfill the target with the new shape. Select a mapping revision and optionally set a batch size, then click **Start Bulk Upload**. | | Source Query Builder | Defines the API query AOH Sync uses to fetch records from your Source System. Set a query name, choose the HTTP method (for example, **GET**), enter the request path, and configure any query parameters. Click **New** to create a query or the refresh icon to reload the list. | ## Understanding the status indicators * **IDLE** — The Connector is not running and is waiting for its next scheduled Sync or a manual trigger. * **RUNNING** — A Sync is in progress. * **MODE** — Shows the ingestion mode (for example, **Hybrid AD**). * **JOIN KEY** — The attribute AOH Sync uses to match incoming records to existing Identities. * **LAST SYNC** — The timestamp of the most recent completed Sync run. * **TELEMETRY** — Whether enhanced telemetry collection is turned on or off for this Connector. The **PIPELINE** diagram shows the three stages of your data flow: the first stage (labeled **Source DB** on screen) connects to your data source, **Mappings** applies your field mapping configuration, and the final stage writes to your connected Target System (shown by its name). A "Connected" badge next to each stage confirms the link is healthy. {% hint style="info" %} The **10 unpublished** badge means you have saved mapping changes that are not yet live. Go to the Mappings tab and publish them to apply the changes to future Syncs. {% endhint %} ## Related * [Sync Types](/core-concepts/sync-types) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Field Mappings](/feature-reference/connectors/field-mappings) * [Revisions & History](/feature-reference/connectors/revisions) * [Schedule](/feature-reference/connectors/schedule) * [Connectors](/feature-reference/connectors) # Field Mappings The Mappings tab lets you define how attributes from your Source System translate into AOH Sync's canonical Identity attributes before they are provisioned to your Target System. ## Where this data comes from Every field mapping starts with a raw attribute column from your Source System — for example, `displayName` or `mail` from an Active Directory source. AOH Sync reads these source columns during each Sync and transforms them into the canonical Identity attributes used across your environment. Mappings you define here never affect the original data in your Source System. ![The Mappings tab for AOH Test AD → CloudSync (Delta), showing a table of Source Column to SCIM Attribute mappings with Active toggles and edit/delete actions](/files/fZZpU489gYnCbEOmlujg) *The Source Field Mappings table shows every attribute translation configured for this Connector, in priority order.* ## What you can do here | Action | What it does | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Auto-Map Columns | Automatically creates mappings by matching Source System column names to known Identity attributes — a quick starting point for new Connectors. | | Add Mapping | Opens a form to manually define a new source-to-Identity attribute mapping. | | Edit a mapping (pencil icon) | Changes the source column, target Identity attribute, or priority for an existing mapping. | | Delete a mapping (trash icon) | Permanently removes the mapping from this Connector. | | Toggle Active switch | Enables or disables a single mapping without deleting it — useful for testing changes before they go live. | ## Understanding the mapping table Each row in the Source Field Mappings table contains: * **#** — The priority order in which mappings are evaluated. Lower numbers run first. * **Source Column** — The raw attribute name as it appears in your Source System (for example, `givenName`, `mail`, `accountEnabled`). * **SCIM Attribute** — The canonical attribute identifier AOH Sync uses for this field (for example, `first_name`, `email`, `status`). * **Active** — Whether this mapping is included in the next Sync run. * **Actions** — Edit or delete the mapping. ## How to use it {% stepper %} {% step %} **Review existing mappings** Open the Mappings tab and scan the table. Confirm that the Source Columns shown match the attributes your Source System actually exports and that the Identity attribute targets are correct. {% endstep %} {% step %} **Add or auto-map** Click **Auto-Map Columns** to let AOH Sync suggest mappings based on your source schema, or click **Add Mapping** to define one manually. Fill in the source column name, select the target Identity attribute, and set a priority number. {% endstep %} {% step %} **Enable or disable individual mappings** Use the Active toggle on each row to include or exclude a mapping from the Sync without deleting it. This is useful for safely testing a schema change. {% endstep %} {% step %} **Publish your changes** After saving edits, return to the Overview tab. If the **unpublished changes** badge is shown, publish your revision so the changes take effect on the next Sync run. {% endstep %} {% endstepper %} {% hint style="info" %} Unpublished mapping changes are tracked as a new revision. You can view and compare any published revision from the [Revisions & History](/feature-reference/connectors/revisions) tab. {% endhint %} ## Related * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) * [Revisions & History](/feature-reference/connectors/revisions) * [Machine Identity Rules](/feature-reference/connectors/machine-identity-rules) * [Connector Overview](/feature-reference/connectors/overview) # Machine Identity Rules The MI Rules tab lets you define rules that automatically classify incoming accounts as Machine Identities — such as service accounts or system users — before they are classified in AOH Sync. ## Where this data comes from Rules are evaluated against each incoming record during a Sync. The source data is the same row your Connector reads from the Source System. When a record's User Principal Name (UPN) matches a rule's pattern, AOH Sync classifies that record as a Machine Identity instead of a standard Account — the original Source System data is unchanged. ![The MI Rules tab for AOH Test AD → CloudSync (Delta), showing an empty rules list and a New Rule form with Rule Type set to UPN Regex, a regex pattern, a Classification label, a Priority field, and an Enabled toggle](/files/l0ISkriB90YJf18blG2i) *The MI Rules tab shows your active classification rules on the left and a form to add a new rule on the right.* ## What you can do here | Action | What it does | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | New rule — Rule type selector | Chooses the matching method for the rule. The available type shown is **UPN regex** (case-insensitive match against the User Principal Name). | | UPN regex field | Enter the regular expression pattern to match against incoming UPN values (for example, `^svc[-_].+` to catch any UPN starting with `svc-` or `svc_`). | | Classification field | A free-text label applied to every account matched by this rule (for example, service\_account). This label is stored with the Machine Identity record. | | Priority field | A numeric value that controls the order in which rules are evaluated. Lower numbers are evaluated first. | | Enabled toggle | Activates or pauses a rule without deleting it. | | Add rule button | Saves the new rule and adds it to the active list. | ## How to use it {% stepper %} {% step %} **Identify your machine account patterns** Review your Source System's user population and identify naming conventions used for service accounts, system accounts, or non-human identities (for example, UPNs beginning with `svc-`, `app-`, or `bot-`). {% endstep %} {% step %} **Set the Rule type** Select **UPN regex** from the Rule type dropdown. This matches accounts by their User Principal Name using a case-insensitive regular expression. {% endstep %} {% step %} **Enter the regex pattern** Type your pattern in the **UPN regex** field. For example, `^svc[-_].+` matches any UPN that starts with `svc-` or `svc_` followed by one or more characters. {% endstep %} {% step %} **Add a Classification label** Type a descriptive label in the **Classification** field (for example, service\_account). This label is stored with the Machine Identity record and helps you identify these accounts in AOH Sync. {% endstep %} {% step %} **Set priority and enable the rule** Enter a **Priority** number. If you have multiple rules, lower numbers are evaluated first — the first match wins. Toggle **Enabled** on, then click **Add rule**. {% endstep %} {% endstepper %} {% hint style="info" %} When no rules are defined, every incoming account is treated as a human Identity. Rules only affect records processed after the rule is saved and enabled — existing records are not reclassified retroactively. {% endhint %} ## Related * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Field Mappings](/feature-reference/connectors/field-mappings) * [Connector Overview](/feature-reference/connectors/overview) * [Connectors](/feature-reference/connectors) # Revisions & History The Revisions tab gives you a full audit trail of every published Field Mapping configuration for this Connector, and lets you compare any revision against the one that preceded it. ![The Revisions tab for AOH Test AD → CloudSync (Delta), showing the Mapping Revisions section with a message that no revisions have been published yet, and a right panel instructing the user to select a revision to view its diff](/files/jVmMAaZHU4MdItZdIgHo) *The Revisions tab lists every published mapping revision and shows a side-by-side diff when you select one.* ## What you can do here | Action | What it does | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------- | | View the revision list | See every published version of this Connector's Field Mappings, in chronological order. | | Select a revision | Loads a diff view in the right panel showing exactly what changed between the selected revision and the one before it. | ## How revisions work Every time you publish a set of Field Mapping changes, AOH Sync creates a new revision entry. Revisions are immutable — once published, the record of what was active at that point in time is preserved. This lets you: * **Audit changes** — See who published what and when. * **Understand impact** — The diff view shows which mappings were added, removed, or modified in each publish. * **Identify the cause** — The diff view shows which revision introduced a change, helping you diagnose unexpected behavior. {% hint style="info" %} The revision list is empty until at least one set of mapping changes has been published. Saving changes on the Mappings tab without publishing does not create a revision. {% endhint %} ## Related * [Field Mappings](/feature-reference/connectors/field-mappings) * [Connector Overview](/feature-reference/connectors/overview) * [Sync History](/feature-reference/connectors/logs) * [Connectors](/feature-reference/connectors) # Schedule The Schedule tab shows the automated Sync schedules configured for this Connector, which control when AOH Sync runs a Sync automatically. ![The Schedule tab for AOH Test AD → CloudSync (Delta), showing the Sync Schedules section with a note that no scheduled jobs exist yet and that they are created automatically when a Target System is added](/files/bSL0v1QOvEiIxCU6S4JM) *The Schedule tab displays any automated Sync schedules assigned to this Connector.* ## What you can do here | Action | What it does | | ------------------- | ---------------------------------------------------------------------------------------- | | View scheduled jobs | See the list of recurring Sync schedules that will trigger this Connector automatically. | ## How schedules work AOH Sync Sync Schedules are created automatically when you add a Target System — you do not need to define them manually. The platform seeds the standard delta and full sync cadences for you based on your Target System configuration. If no Target System has been connected to this Connector yet, the Schedule tab shows a message indicating that no scheduled jobs exist. Once a Target System is added, the canonical schedule entries appear here. {% hint style="info" %} To trigger a Sync immediately without waiting for the next scheduled run, use the **Run Now** button on the Connectors list page. {% endhint %} ## Related * [Sync Types](/core-concepts/sync-types) * [Connector Overview](/feature-reference/connectors/overview) * [Sync History](/feature-reference/connectors/logs) * [Connectors](/feature-reference/connectors) # Sync History The Sync History view shows a time-ordered log of every inbound Sync run for this Connector, so you can confirm that data is flowing correctly and investigate any failures. ![The Sync History view for AOH Test AD → CloudSync (Delta), showing a table of recent sync runs with columns for Started, Status, Duration, Records, and Detail](/files/S1OBiEcvmmPCDFtl1XqV) *The Sync History table lists recent Sync runs with their start time, status, duration, record count, and detail.* ## What you can do here | Action | What it does | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Refresh | Manually reloads the Sync History table. The view updates automatically every 5 seconds. | | Review run rows | Each row shows the start time, outcome status, how long the run took, how many records were processed, and an additional detail column indicating the sync method used. | ## Understanding the Sync History table Each row in the Sync History table represents one completed or in-progress Sync run: * **Started** — The date and time the Sync run began. * **Status** — The outcome of the run. Typical statuses include **succeeded** (completed without errors) and **running** (currently in progress). * **Duration** — How long the Sync took to complete, shown in seconds. * **Records** — The number of records processed during this run. A dash (—) indicates that record-level counts were not captured for that run. * **Detail** — Additional context about the run, such as the method used to retrieve data (for example, `via entra_id`). {% hint style="info" %} The Sync History view updates automatically every 5 seconds. Click **Refresh** at any time to load the latest data immediately. {% endhint %} ## Related * [Sync Types](/core-concepts/sync-types) * [Schedule](/feature-reference/connectors/schedule) * [Revisions & History](/feature-reference/connectors/revisions) * [Connector Overview](/feature-reference/connectors/overview) * [Connectors](/feature-reference/connectors) # Settings The Settings tab lets you configure how this Connector behaves during provisioning — including whether it is active, how it matches incoming records to existing Identities, and which attributes it uses as a join key. ![The Connector Settings tab for AOH Test AD → CloudSync (Delta), showing Provisioning Enabled toggle, App Display Name field, and an Identity Matching section with Identity Mode selector and Join Key field](/files/tgH6RFLyXXEBAezlZx8o) *The Connector Settings tab controls provisioning behavior, display name, and identity matching for this Connector.* ## What you can do here | Action | What it does | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Provisioning Enabled toggle | Enables or disables all Sync operations for this Connector. When disabled, no data is written to the Target System during a Sync run. | | App Display Name | Sets the human-readable name for this Connector. This is the display name of the Enterprise Application in Entra ID. | | Identity Mode selector | Controls how incoming records are matched to existing Identities. The example shown is **Delta (ingestion)**, which uses an incremental matching strategy. | | Join Key field | A comma-separated list of canonical attribute names AOH Sync uses — in priority order — to match an incoming record to an existing Identity. The first attribute that produces a match wins. | | Telemetry toggle | Enables or disables the collection of provisioning telemetry data for this Connector. When on, AOH Sync sends telemetry data for monitoring and diagnostics. | | Connection Info | Read-only reference section showing this Connector's Tenant ID, creation date, last-updated timestamp, and current status. | ## Understanding the Identity Matching settings **Identity Mode** determines the strategy AOH Sync uses when deciding whether an incoming record is a new Identity or an update to an existing one. The mode shown in the demo is **Delta (ingestion)**, which processes only changed records since the last Sync. Select the mode that matches how your Source System delivers data to AOH Sync. **Join Key** is the list of canonical attributes AOH Sync evaluates to find an existing Identity for each incoming record. In the demo, the join key is `userPrincipalName,email,employeeId` — AOH Sync tries `userPrincipalName` first, then falls back to `email`, then `employeeId`. If no match is found on any attribute, AOH Sync creates a new Identity record. Leaving the Join Key empty falls back to default UPN/email/displayName matching. **Telemetry** controls whether AOH Sync collects provisioning telemetry data for this Connector. Enabling it sends diagnostic signals that help identify Sync issues. It can be toggled independently of provisioning. The **Connection Info** section is read-only and shows reference identifiers for this Connector: its Tenant ID, creation date, last-updated timestamp, and current status. Use these values if you need to identify the Connector in support requests or audit logs. {% hint style="warning" %} Disabling the **Provisioning Enabled** toggle stops all Sync operations for this Connector immediately. No data will be written to or removed from your Target System until you re-enable it. {% endhint %} ## How to use it {% stepper %} {% step %} **Confirm provisioning is enabled** Check that the **Provisioning Enabled** toggle is on. If you need to pause all Sync activity for this Connector, turn it off here. {% endstep %} {% step %} **Set the App Display Name** Enter the name you want to appear for this Connector. This becomes the display name of the Enterprise Application in Entra ID. Use a name that clearly identifies the source and target (for example, `HR System → AOH Sync`). {% endstep %} {% step %} **Choose the Identity Mode** Select the mode that matches how your Source System delivers data to AOH Sync. {% endstep %} {% step %} **Define the Join Key** Enter a comma-separated list of canonical attribute names in the order you want AOH Sync to try them. The first attribute that matches an existing Identity wins. Leave blank to use the default matching behavior. {% endstep %} {% step %} **Configure Telemetry** Turn the **Telemetry** toggle on to enable provisioning telemetry collection for this Connector, or leave it off to disable it. This setting does not affect Sync operations. {% endstep %} {% endstepper %} ## Related * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Sync Types](/core-concepts/sync-types) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) * [Field Mappings](/feature-reference/connectors/field-mappings) * [Connector Overview](/feature-reference/connectors/overview) * [Connectors](/feature-reference/connectors) # Source Systems The Source Systems page is where you connect and manage the external data sources whose Account records AOH Sync imports into your Identity store. ## Where this data comes from Source Systems are the authoritative records you own — HR platforms, collaboration tools, and other directories. AOH Sync reads Account data from each connected Source System on a schedule you control; it never writes back to your Source Systems. ![Source Systems page showing five connected systems — Bamboo, GitHub, Okta, Slack, and WorkDay — in two panels: an Account import panel where each system shows "Account import configured" and an "Ingestion configured" badge, and a GROUP Manual CSV panel listing the same five systems each with a "Manual CSV" badge and a chevron toggle](/files/3lzd0fNI0Yry0krnrMZv) *The Source Systems page shows two panels. The top **Account import** panel lists each system with its ingestion status. The lower **GROUP Manual CSV** panel groups the same systems by their data-delivery method; expand a row with the chevron toggle to see its connection details.* ## What you can do here | Action | What it does | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **+ Add Source System** | Opens the setup flow to connect a new Source System to AOH Sync. | | Expand a row in the **GROUP Manual CSV** panel | Click the chevron toggle on a system row to reveal its connection details and ingestion configuration. | | Click a Source System name | Opens the detail view for that Source System where you can adjust settings. | ## Adding a Source System Click **+ Add Source System** to open the setup flow. Choose the system type from the dropdown — available types include HR platforms (Gusto, ADP), relational databases (SQL Server, MySQL, and others), file feeds (CSV upload or CSV over SFTP), and LDAP directories. Supply the connection details for your chosen type and click **Save**. AOH Sync tests the connection and, if successful, adds the system to the list and automatically creates an Account Import connector for it. For a step-by-step first-time walkthrough, see [Connect a Source System](/getting-started/07-connect-source-system). ## Related * [Source & Target Systems](/core-concepts/source-and-target-systems) * [Connectors](/feature-reference/connectors) * [Field Mappings](/feature-reference/connectors/field-mappings) * [How AOH Sync Works](/core-concepts/how-aohsync-works) # Target Systems (Entra) The Target Systems page lists every directory or service that AOH Sync provisions identities into, along with live health metrics and active provisioning rules for each one. ## Where this data comes from Data displayed on the Target Systems page is read directly from your connected Entra tenant. AOH Sync queries the tenant in real time for health metrics and pulls provisioning rule status from your configured rules; it does not store a separate copy of this information. ![Target Systems page showing an internal SYNC destination and an AOH Test AD Active Directory target with provisioning rules and a Tenant health panel](/files/7JUkYyvhR0J8mcoD0KRW) *The AOH Test AD target shows four provisioning rules (Joiner -> AD + Azure, Mover -> AD + Azure, Leaver -> AD + Azure, and Contractor cleanup) and a Tenant health panel. Rule destination labels reflect your configuration and may vary.* ## What you can do here | Action | What it does | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **+ Add Target System** | Opens the setup flow to connect a new Target System. | | Expand a Target System row | Reveals the Provisioning rules and Tenant health panels for that target. | | **View all** (Provisioning rules) | Opens the full list of provisioning rules for the selected Target System. | | Toggle a provisioning rule On / Off | Enables or disables that rule without deleting it. | | Click a Target System | Navigates to the Identity Management tabs (Directory, Enterprise Apps, Security, Compliance, Helpdesk) for that target. | | Review **Provisioning success** | Shows the percentage of provisioning operations that completed successfully in the last 24 hours. | | Review **Avg target latency** | Shows the average time AOH Sync takes to apply a change to the target directory. | | Review **Schema drift events** | Shows how many times a structural change was detected in the target directory schema since the last check. | | Review **Disabled accounts** | Shows the number of accounts in the target directory that are currently disabled. | ## Adding a Target System Click **+ Add Target System** to open the four-step setup wizard. Choose your provisioning topology (Entra ID for cloud-only, or Active Directory for hybrid), complete the Azure setup checklist, and enter the credentials from your Enterprise Application. AOH Sync automatically creates an Identity Ingestion connector for the new target after saving. For a step-by-step first-time walkthrough, see [Connect a Target System](/getting-started/08-connect-target-system). ## Related * [Source & Target Systems](/core-concepts/source-and-target-systems) * [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle) * [Connectors](/feature-reference/connectors) * [Directory](/feature-reference/target-systems/directory) * [Applications](/feature-reference/target-systems/applications) * [Security](/feature-reference/target-systems/security) * [Helpdesk](/feature-reference/target-systems/helpdesk) # Directory The Directory tab lets you search your connected Entra target's user directory by name or email address, and view identity sources and lifecycle events for any user you find. ![Directory tab of the Identity Management screen for AOH Test AD, with a search field to find users by name or email, a Search button, and a Filters control](/files/W9YcRkEZVDxZ2RXnAh8D) *The Directory tab opens with an empty search state; enter a name or email address and click Search to locate a user.* ## What you can do here | Action | What it does | | ----------------------------------------- | -------------------------------------------------------------------------------- | | Enter a name or email in the search field | Scopes the directory lookup to matching users. | | Click **Search** | Runs the query against your connected Entra target and returns matching results. | | Click **Filters** | Applies additional filters to narrow search results. | | Click a result | Opens that user's detail view, showing identity sources and lifecycle events. | ## How to use it {% stepper %} {% step %} **Open the Directory tab** Navigate to **Target Systems**, expand your Entra target, and click the target name. Select the **Directory** tab. {% endstep %} {% step %} **Enter a name or email** Type the user's full name, partial name, or email address into the search field. {% endstep %} {% step %} **Review results** Click **Search** to retrieve matching users. Click any row to see the full identity record including sources and lifecycle history. {% endstep %} {% endstepper %} ## Related * [Target Systems](/feature-reference/target-systems) * [Identities](/feature-reference/browsing-identities/identities) * [Source & Target Systems](/core-concepts/source-and-target-systems) # Applications The Enterprise Apps tab lists the enterprise applications registered in your connected Entra Target System so you can review, search, and filter them. ## Where this data comes from Enterprise application records are read directly from your connected Entra tenant. AOH Sync does not create or modify these records. ## What you can do here | Action | What it does | | ------------------------ | --------------------------------------------------------------------------------- | | **Search apps** | Finds a specific application by name using the search field. | | **Stale apps only** | Filters the list to applications that have not been used recently. | | **Expiring credentials** | Filters the list to applications whose secrets or certificates are expiring soon. | | **Refresh** | Reloads the application list from your Entra tenant. | ## Related * [Target Systems](/feature-reference/target-systems) * [Security](/feature-reference/target-systems/security) * [Source & Target Systems](/core-concepts/source-and-target-systems) # Security The Security tab lets you review Conditional Access policies and MFA posture for your connected Entra target, giving you a consolidated view of your access control configuration. ## What you can do here | Action | What it does | | ---------------------------- | ---------------------------------------------------------------------- | | Click **Conditional Access** | Lists the Conditional Access policies configured in your Entra tenant. | | Click **MFA Posture** | Shows the MFA configuration status for users in your Entra tenant. | | Search policies | Finds a specific Conditional Access policy by name. | | Filter by **All States** | Narrows the policy list by state (enabled, disabled, or report-only). | | **Refresh** | Reloads the policy list from your Entra tenant. | ## Related * [Target Systems](/feature-reference/target-systems) * [Applications](/feature-reference/target-systems/applications) * [Source & Target Systems](/core-concepts/source-and-target-systems) # Helpdesk The Helpdesk tab lets you look up any user in your connected Entra target by User Principal Name (UPN) or Object ID, giving support teams a fast way to locate user records without leaving AOH Sync. ![Helpdesk tab of the Identity Management screen for AOH Test AD, showing a User Object ID or UPN input field and a Look up user button](/files/0cMe9axxL6ecKgXNTg8n) *Enter a UPN (e.g. ) or Object ID and click Look up user to retrieve that user's Entra record.* ## What you can do here | Action | What it does | | ------------------------ | ---------------------------------------------------------------------- | | Enter a UPN or Object ID | Identifies the user you want to look up in the connected Entra tenant. | | Click **Look up user** | Retrieves and displays the user's record from the Entra tenant. | ## How to use it {% stepper %} {% step %} **Open the Helpdesk tab** Navigate to **Target Systems**, expand your Entra target, and click the target name. Select the **Helpdesk** tab. {% endstep %} {% step %} **Enter the user's identifier** Type the user's UPN (for example, `user@contoso.com`) or their Entra Object ID into the input field. {% endstep %} {% step %} **Look up the user** Click **Look up user** to retrieve the user's record from the connected Entra tenant. {% endstep %} {% endstepper %} ## Related * [Target Systems](/feature-reference/target-systems) * [Directory](/feature-reference/target-systems/directory) * [Identities](/feature-reference/browsing-identities/identities) # Browsing Identities The Identities list is your unified view of every person AOH Sync has resolved across all your connected systems — searchable, filterable, and sortable. ## Where this data comes from Identities are assembled by AOH Sync from the Accounts it collects across your connected Source Systems and Target Systems. When multiple Accounts from different systems belong to the same person, AOH Sync merges them into a single Identity record. The data you see here reflects the most recent Sync across all your Connectors. ![Identities list showing canonical identity records with columns for Name, Status, Email, Title, Sources, Accounts, and Last Updated](/files/0DbLqz5uV2bV9HtMiUs4) *The Identities list shows all resolved Identities in alphabetical order. Each row shows the Identity's name, active status, number of connected Source Systems (Sources), number of linked Accounts, and when the record was last updated.* ## What you can do here | Action | What it does | | ----------------------------- | ---------------------------------------------------------------------------- | | Search by name, UPN, or email | Filters the list to Identities matching the text you enter. | | Filter by **All statuses** | Narrows the list to Identities with a specific status (for example, active). | | Sort by any column | Reorders the list by Name, Status, or Last Updated. | | **Refresh** | Reloads the Identity list with the latest data from the most recent Sync. | | Click an Identity row | Opens the full detail view for that Identity. | ## Related * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Identity Detail](/feature-reference/browsing-identities/identities) * [Source Systems](/feature-reference/source-systems) # Identities The Identity detail page shows the full resolved profile for a single Identity — every attribute, where each value came from, and how the Identity connects to your directory. ## Where this data comes from Identity detail data is assembled from the Account records your Connectors have synced from your connected Source Systems. Attribute values, priority scores, and linked Accounts all reflect the most recent Sync. ![Identity detail page for Aaliyah Bartlett showing Properties, Graph, History, and Assignments tabs, with an Attributes table listing fields, values, source systems, priority scores, and last-updated timestamps](/files/wxJh4xI1QMdbvB6Hkgvb) *The Properties tab shows each resolved attribute (department, email, job title, etc.) with a "winner" badge on the highest-priority value, plus the Source System that provided it and when it was last updated.* ## What you can do here | Action | What it does | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Click **Properties** | Displays the full attribute table: field names, resolved values, source, priority, and last-updated timestamp. | | Click **Graph** | Opens the relationship graph view for this Identity. | | Click **History** | Shows the change history for this Identity's attributes over time. | | Click **Assignments** | Lists the groups, roles, or entitlements assigned to this Identity. | | Review the **Attributes** table | Identifies which Source System's value won for each field and at what priority level. | | Review **Linked Users** | Shows the user records in your connected Target Systems that belong to this Identity. | | Review **Linked Accounts** | Shows the Accounts from your Source Systems that have been merged into this Identity. | | Review **Machine Identities** | Shows non-human accounts owned by this Identity. A count of zero means no Machine Identities are currently linked. | ## Understanding field names Field names in the Attributes table (for example, `first_name`, `user_principal_name`, `external_id`) reflect the identifiers used in your source systems' data model. These are the raw field keys AOH Sync receives from each Source System; they are not display labels. Use the **SOURCE** and **PRIORITY** columns to understand which system provided each value and why it was selected. ## Understanding priority resolution When multiple Accounts contribute a value for the same field, AOH Sync uses a priority score to decide which value to display on the Identity. The row marked **winner** is the value that all downstream systems and reports use. The priority number shown is the weight assigned to that Source System in your Connector configuration — higher numbers win. ## Related * [Browsing Identities](/feature-reference/browsing-identities) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Source Systems](/feature-reference/source-systems) * [Connectors](/feature-reference/connectors) # Accounts The Accounts screen lists every source-system account record AOH Sync has discovered across all your connected Source Systems. ## Where this data comes from Accounts originate from your connected Source Systems — AOH Sync reads them during each Sync and never creates them on its own. Every row represents a single account record as it exists in the source, linked back to the Identity it belongs to. ![The Accounts screen showing a searchable, sortable list of source-system account records with columns for Name, Status, Identifier, Role, and Last Updated, and a "Flag as machine identity" action on each row](/files/6cVxDVew8Ih4zvk4FMnX) *The Accounts screen displays all account records pulled from your connected Source Systems. Each row shows the account's current status, its unique identifier from the source, and when it was last updated by a Sync.* ## What you can do here | Action | What it does | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Search by name, identifier, or external ID | Filters the list to accounts matching your search term. | | Filter by status | Use the **All statuses** dropdown to narrow the list to accounts with a specific status (for example, active only). | | Sort any column | Click a column header to sort ascending or descending. Sortable columns include Name, Status, Identifier, Role, and Last Updated. | | **Flag as machine identity** | Marks the account as a Machine Identity, moving it to the Machine Identities list and removing it from your standard Identities list. | | **Refresh** | Reloads the account list to show the latest data from the most recent Sync. | ## How to use it {% stepper %} {% step %} **Find an account** Use the search box to look up an account by name, identifier, or external ID. Use the status filter to narrow results if you are looking for active, disabled, or another category of account. {% endstep %} {% step %} **Review account details** Check the **Identifier** column for the account's unique ID in the source system, the **Role** column for any role assignment, and **Last Updated** for when AOH Sync last received data for this account. {% endstep %} {% step %} **Flag a service or automation account** If an account belongs to a service, automated process, or application rather than a real person, click **Flag as machine identity**. AOH Sync reclassifies it as a Machine Identity so your security team can track it separately with a risk score and owner. {% endstep %} {% endstepper %} ## Related * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Machine Identities](/core-concepts/machine-identities) * [Machine Identities (feature)](/feature-reference/browsing-identities/machine-identities) * [Identities](/feature-reference/browsing-identities/identities) # Machine Identities The Machine Identities screen lists every non-human account AOH Sync has identified across your connected Source Systems — service accounts, automation users, shared mailboxes, and application identities. ## Where this data comes from Machine Identities are identified from the account data your Source Systems provide during each Sync. AOH Sync classifies accounts as Machine Identities either automatically, based on Machine Identity Rules configured on your Connectors, or manually when you flag an account from the Accounts screen. Each Machine Identity carries a risk score, a type classification, an owner, and a status derived from the source data. ![The Machine Identities screen showing two tabs — Confirmed and Suggestions — with a sortable list of machine identity records and columns for Name, Type, Owner Identity, Risk, and Status, plus a Details action on each row](/files/ZAuDtwX5omTHhRPIHXSf) *The Machine Identities screen shows all confirmed and suggested non-human accounts. The Risk column displays a numeric score on a 0–1 scale (higher is riskier) with a color-coded bar: green for low, yellow for medium, and red for high. The Type column classifies each account as application, automation, service account, or system.* ## What you can do here | Action | What it does | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Switch between **Confirmed** and **Suggestions** tabs | **Confirmed** shows accounts already classified as Machine Identities. **Suggestions** shows accounts AOH Sync has automatically identified as likely Machine Identities based on your Machine Identity Rules, pending your review. | | Sort any column | Click a column header to sort the list by Name, Type, Owner Identity, Risk (0–1 scale), or Status. | | **Refresh** | Reloads the list to show data from the most recent Sync. | | **Details** | Opens the full record for a Machine Identity, including its classification, owner, risk history, and associated accounts. | ## How to use it {% stepper %} {% step %} **Review confirmed Machine Identities** The **Confirmed** tab shows all accounts your team has designated as Machine Identities. Check the **Risk** column — a score close to 1.0 (shown in red) indicates an account that may need attention. Click **Details** to investigate further. {% endstep %} {% step %} **Review suggestions** Switch to the **Suggestions** tab to see accounts AOH Sync flagged automatically. Confirm or dismiss each suggestion to keep your Machine Identity list accurate. {% endstep %} {% step %} **Track ownership** Use the **Owner Identity** column to verify that every Machine Identity has a responsible owner. Accounts with no owner (shown as —) should be reviewed and assigned. {% endstep %} {% endstepper %} ## Related * [Machine Identities (concept)](/core-concepts/machine-identities) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Accounts](/feature-reference/browsing-identities/accounts) * [Machine Identity Rules](/feature-reference/connectors/machine-identity-rules) # Action Center The Action Center surfaces actionable issues across your connected systems — data gaps, ownership problems, and configuration findings — so you can resolve them before they become risks. ![Action Center page showing four sections: Configuration (no issues), Sync (no issues), System (no issues), and Data — with five open items including activity data gaps, unmatched accounts, unowned service principals, machine identities with no inheritor, and empty groups; plus a USERS / PEOPLE section with individual user items](/files/K8WObPAZ00y4w8m0I4RH) *The Action Center groups issues by category. The Data section surfaces data quality issues — each with a severity badge (HIGH, MEDIUM, or LOW) and a direct action button. A separate Users / People section lists individual user-level findings.* ## What you can do here | Action | What it does | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Review **Configuration** section | Shows any setup or connection issues that need attention. | | Review **Sync** section | Shows any issues with recent Sync runs across your Connectors. | | Review **System** section | Shows any platform-level issues affecting AOH Sync. | | Review **Data** section | Shows data quality issues such as users with no activity data (MEDIUM), unmatched Accounts (HIGH), unowned enterprise applications (HIGH), Machine Identities with no technical inheritor (MEDIUM), and groups with no members (LOW). | | Review **Users / People** section | Lists individual user records with specific findings, such as no sign-in, lifecycle, or source-updated data on any linked account. | | Click **Open source systems** | Opens Source Systems so you can investigate why users have no activity data. | | Click **Resolve orphans** | Opens the Orphaned Accounts view to resolve Accounts with no matching Identity. | | Click **Review machine identities** | Opens the Machine Identities view to assign owners or technical inheritors. | | Click **Review access management** | Opens Access Management to address groups that have no members. | | Click **View accounts** | Opens the Accounts view for the specific user listed in the Users / People section. | | Click **×** on an issue | Dismisses that issue from the active list. | | Toggle **Show dismissed** | Reveals issues you have previously dismissed, so you can review or restore them. | ## How to use it {% stepper %} {% step %} **Open the Action Center** Click **Action Center** in the left navigation. The badge next to the label shows the current number of open issues. {% endstep %} {% step %} **Review each section** Work through Configuration, Sync, System, Data, and Users / People sections. Items with a **HIGH** badge should be addressed first. {% endstep %} {% step %} **Act or dismiss** Click the action button on each item (for example, **Resolve orphans**) to go directly to the relevant page, or click **×** to dismiss items you have already handled elsewhere. {% endstep %} {% endstepper %} ## How to investigate and resolve an issue Use the Action Center as a daily triage queue: work from HIGH to LOW severity, act on each item, then dismiss what you have handled. {% stepper %} {% step %} **Open the Action Center** Click **Action Center** in the left navigation. The badge next to the label shows the total number of open issues. {% endstep %} {% step %} **Identify the highest-severity items** Scan the DATA section for **HIGH** badges first — these represent the most urgent risks. The two HIGH items on a typical tenant are unmatched Accounts ("accounts matched to no person") and unowned service principals ("service principals have no owner"). **MEDIUM** items (no activity data, no technical inheritor) and **LOW** items (empty groups) can follow. {% endstep %} {% step %} **Open an item's detail view** Click the action button on the right side of the issue card to go directly to the relevant screen: | Issue | Action button | Where it takes you | | ---------------------------------------------- | ----------------------------- | ----------------------- | | Users with no activity data | **Open source systems** | Source Systems page | | Accounts matched to no person | **Resolve orphans** | Orphaned Accounts view | | Service principals with no owner | **Review machine identities** | Machine Identities view | | Machine identities with no technical inheritor | **Review machine identities** | Machine Identities view | | Groups with no members | **Review access management** | Access Management page | | {% endstep %} | | | {% step %} **Take the resolution action** On the destination screen, assign ownership, match the Account to an Identity, or remove the stale record as appropriate. Return to the Action Center once you have addressed the item. {% endstep %} {% step %} **Dismiss resolved or accepted items** Click **×** on an issue card to dismiss it from the active list. For the Users / People section, click **Dismiss all (21)** to clear all individual user findings at once. To review items you have dismissed, toggle **Show dismissed** in the top-right corner of the Action Center. {% endstep %} {% endstepper %} {% hint style="info" %} Dismissals are recorded in AOH Sync so you can always surface them again with **Show dismissed**. Dismissing an item does not fix the underlying data — it acknowledges that you have reviewed it. {% endhint %} ## Related * [Orphaned Accounts](/feature-reference/orphaned-accounts) * [Browsing Identities](/feature-reference/browsing-identities) * [Connectors](/feature-reference/connectors) * [How AOH Sync Works](/core-concepts/how-aohsync-works) # Orphaned Accounts The Orphaned Accounts page lists every Account that AOH Sync found in a Source System but could not match to any known Identity, so you can investigate and resolve each one. ## Where this data comes from Orphaned Accounts originate from the Account records that your Connectors pull from each connected Source System. When an Account cannot be matched to an existing Identity using the configured join keys — because the person has left, changed their identifier, or the account genuinely belongs to no current person — AOH Sync marks it as an orphan and surfaces it here for review. Common reasons an account becomes an orphan: * A new hire exists in payroll before their login account is created (a timing gap that resolves itself). * A record uses a different identifier than the one AOH Sync matches on (a data quality issue). * The account genuinely belongs to no current person — a leftover, a mistake, or an unmarked service account (real risk). Tracking orphans is how you tell timing gaps apart from actual unmanaged access. ![Orphaned Accounts (Orphan Management) page showing a list of unresolved accounts with columns for Account, Source System, Risk, Status, Discovered, and Actions](/files/lTlpKZ6yEfBSZtK4LlSp) *The Orphan Management page lists unresolved accounts (ernesto from GitHub, thaddeus from Okta, xavier and dustin from Slack, dwight from AOH Test AD, and others) each with a numerical risk score and a base risk comparison. Use the Source system filter to narrow by source, or sort any column to prioritise your review.* ## How risk scores work Each orphan carries a **risk score** between 0.0 and 1.0. The score combines a baseline risk with the length of time the orphan has gone unresolved: the longer an account sits unmatched, the higher it scores — automatically, without anyone having to remember to revisit it. A brand-new orphan may be a harmless timing gap; that same account unresolved weeks later signals a real governance problem. Scores are recomputed on a regular cycle so time acts as a risk multiplier. AOH Sync also surfaces **match suggestions** for each orphan: the most likely existing Identities ranked by confidence, so you can confirm a match rather than search for one. ## What you can do here | Action | What it does | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Filter by **Status** | Narrows the list to orphans in a specific state — for example, Unresolved. | | Filter by **Source system** | Shows orphans from a single connected Source System only. Use the source system filter field to narrow the list by source system name. | | **Refresh** | Reloads the list with the latest data. | | Sort by any column | Reorders the list by Account name, Source System, Risk, Status, or Discovered date. | | Click **Actions** | Opens a menu of resolution options for that orphan: match to an existing Identity, create a new Identity, mark as a Machine Identity, or dismiss. | ## How to use it {% stepper %} {% step %} **Filter to Unresolved** Open **Orphaned Accounts** from the left navigation. Confirm the Status filter is set to **Unresolved** to see only items that need action. {% endstep %} {% step %} **Review risk scores** The Risk column shows a numerical score for each orphan. Higher scores indicate a greater likelihood that the account represents an active, unmanaged access risk. Start with the highest-risk rows. {% endstep %} {% step %} **Resolve each orphan** Click **Actions** on a row and choose the appropriate resolution: match the account to a known Identity, create a new Identity for it, designate it as a Machine Identity, or dismiss it if it is expected. {% endstep %} {% endstepper %} ## Related * [Action Center](/feature-reference/data-quality) * [Identities, Accounts & Users](/core-concepts/identities-accounts-users) * [Source Systems](/feature-reference/source-systems) * [Browsing Identities](/feature-reference/browsing-identities) # Scheduling & Orchestration The Orchestration page gives you a live, visual overview of every active Connector and tenant across your AOH Sync environment, along with headline health metrics. ![Orchestration page showing a star-map style graph with connected nodes, and a metrics bar at the top displaying Tenants: 2, Users: 1,531, Tracked Accounts: 3,051, Connectors: 6, Health: 50%, Errors 24h: 0](/files/0JLfPEjJcKhSPI2kysbm) *The Orchestration view displays a live relationship graph of your connected tenants and Connectors. The metrics bar summarizes 2 Tenants, 1,531 Users, 3,051 Tracked Accounts, 6 Connectors, 50% Health, and 0 errors in the last 24 hours.* ## What you can do here | Action | What it does | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Review the **Tenants** metric | Shows the number of Entra tenants currently connected to AOH Sync. | | Review the **Users** metric | Shows the total number of resolved Identities across all connected tenants. | | Review the **Tracked Accounts** metric | Shows the total number of Accounts AOH Sync is actively monitoring across all Source Systems (currently 3,051). | | Review the **Connectors** metric | Shows the number of active Connectors. | | Review the **Health** metric | Shows the overall health percentage across your Connectors (the percentage of your Connectors currently operating without errors). | | Review the **Errors 24h** metric | Shows the count of Connector errors in the last 24 hours. | | Interact with the graph | Pan and zoom the visual to explore connections between tenants and Connectors. | ## Related * [Connectors](/feature-reference/connectors) * [Source Systems](/feature-reference/source-systems) * [Target Systems](/feature-reference/target-systems) * [How AOH Sync Works](/core-concepts/how-aohsync-works) # Schedule The Schedule screen gives you a central view of all automated Sync jobs running across your AOH Sync environment — including their cadence, event type, target, and recent run history. ![The Schedule screen showing a "Scheduled Jobs" table with columns for Name, Schedule, Event Type, Target, Status, and Actions (Enable, Disable, Trigger now, Delete), and a "Recent Runs" table below with columns for Run, Job, Status, Started, Finished, Retries, Error, and Actions](/files/jLpEu7IW9kWhsYkhRHsI) *The Schedule screen shows all active Sync jobs at the top and a live feed of recent runs below. Each job can be triggered on demand or disabled without deleting it.* {% hint style="info" %} This is the environment-wide Schedule screen. For the schedule configured on a specific Connector, see [Connector Schedule](/feature-reference/connectors/schedule). For the visual Orchestration overview, see [Scheduling & Orchestration](/feature-reference/scheduling-orchestration). {% endhint %} ## Where this data comes from Scheduled jobs are created directly in AOH Sync — they are not pulled from an external system. The Recent Runs table fills in automatically as jobs execute: AOH Sync writes a run record every time a sync runs, whether it was triggered on schedule or on demand. ## What you can do here | Action | What it does | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | View scheduled jobs | See all active Sync jobs with their name, cadence (for example, "Every 5 minutes" or "At 02:00 AM"), event type (such as `sync.delta` for incremental syncs or `sync.full` for full syncs), target, and current status. | | **Enable** | Activates a job that was previously disabled so it resumes running on its configured schedule. | | **Disable** | Pauses a job without deleting it. The job remains visible and can be re-enabled at any time. | | **Trigger now** | Runs the job immediately, outside of its normal schedule. Useful for testing or forcing a sync after a configuration change. | | **Delete** | Permanently removes the scheduled job. | | **Create a New Job** | Opens the form to define a new scheduled Sync job with a name, cadence, event type, and target. | | View recent runs | The **Recent Runs** table shows the run identifier, which job it belongs to, its status (for example, complete), the start and finish times, retry count, and any error details. | ## How to use it {% stepper %} {% step %} **Review job health** Check the **Status** column in the Scheduled Jobs table. All jobs should show **Active**. If a job is disabled or missing, investigate whether it was paused intentionally. {% endstep %} {% step %} **Trigger a sync on demand** Click **Trigger now** next to the job you want to run. The new run appears at the top of the **Recent Runs** table within moments. {% endstep %} {% step %} **Investigate a failed run** Find the run in the **Recent Runs** table and check the **Error** and **Retries** columns. Click the action for that run to view full details. {% endstep %} {% step %} **Create a new scheduled job** Click **Create a New Job** in the top-right corner, fill in the job name, schedule cadence, event type, and target, then save. {% endstep %} {% endstepper %} ## Related * [Connector Schedule](/feature-reference/connectors/schedule) * [Scheduling & Orchestration](/feature-reference/scheduling-orchestration) * [Sync Types](/core-concepts/sync-types) # Reports The Reports page lets you generate one-off PDF reports and manage recurring report schedules with automated delivery. ![Reports page showing three summary metric cards (Schedules: 0, Enabled: 0, Reports run: 0), a Generate tab with Suggested filter tags, a Select all link, six report section cards, and a Generate report button](/files/hMqeAfqnFRQBceYKCUT4) *The Reports page shows summary cards for Schedules, Enabled schedules, and Reports run. The Generate tab lists six available report sections with Suggested filter tags. Select one or more sections and click **Generate report** to produce a PDF.* ## What you can do here | Action | What it does | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Review **Schedules** card | Shows how many recurring report schedules you have configured. | | Review **Enabled** card | Shows how many of your configured schedules are currently active. | | Review **Reports run** card | Shows the total number of reports that have been generated. | | Click **Generate** tab | Shows the section picker for building an on-demand report. | | Click **Schedules** tab | Lists any recurring report schedules you have configured, and lets you add new ones. | | Click **History** tab | Shows previously generated reports available for download. | | Click a **Suggested** filter tag | Pre-selects a curated set of sections matching a use case — **Security**, **Audit & Compliance**, **Executive**, or **Everything**. | | Click **Select all** | Selects all six report sections at once. | | Select **Overview KPIs** | Includes headline metrics for your connected tenant in the report. | | Select **Access Overview** | Includes a breakdown of who can reach what, by system. | | Select **Orphans** | Includes a list of Accounts with no owning Identity. | | Select **Posture** | Includes configuration and hardening findings for your environment. | | Select **Sign-in Anomalies** | Includes unusual authentication activity detected across your tenant. | | Select **Directory Changes** | Includes recent additions, removals, and updates from your directory. | | Click **Generate report** | Produces a PDF containing the sections you selected. | ## How to use it {% stepper %} {% step %} **Choose your sections** On the **Generate** tab, check the boxes next to the report sections you want to include. You can select one or more sections. {% endstep %} {% step %} **Generate the report** Click the **Generate report** button. AOH Sync compiles the selected data into a PDF. {% endstep %} {% step %} **Access previous reports** Click the **History** tab to find and download any reports you have generated in the past. {% endstep %} {% step %} **Set up recurring delivery** Click the **Schedules** tab to create a recurring report schedule and configure delivery settings. {% endstep %} {% endstepper %} ## How to generate and schedule a report Use the **Generate** tab to build a one-off PDF, or the **Schedules** tab to set up recurring delivery. {% stepper %} {% step %} **Select your sections** On the **Generate** tab, pick the report content you need. You have two ways to select sections: * Click a **Suggested** filter tag — **Security**, **Audit & Compliance**, **Executive**, or **Everything** — to pre-select a curated set of sections for that use case. * Check individual section cards: **Overview KPIs**, **Access Overview**, **Orphans**, **Posture**, **Sign-in Anomalies**, or **Directory Changes**. Click **Select all** to include every section at once. The bar at the bottom of the section picker updates to show how many sections are selected. {% endstep %} {% step %} **Generate the report** Click the green **Generate report** button. AOH Sync compiles your selected sections into a PDF. {% endstep %} {% step %} **Find previously generated reports** Click the **History** tab to see reports you have generated in the past and download them again. {% endstep %} {% step %} **Set up a recurring schedule** Click the **Schedules** tab to configure automated report delivery. {% endstep %} {% endstepper %} {% hint style="info" %} The **Schedules**, **Enabled**, and **Reports run** summary cards at the top of the page update as you add schedules and generate reports. {% endhint %} ## Related * [Dashboard](/feature-reference/dashboard) * [Orphaned Accounts](/feature-reference/orphaned-accounts) * [Action Center](/feature-reference/data-quality) * [How AOH Sync Works](/core-concepts/how-aohsync-works) # Access Management Manage the permission groups that control what each user can see and do in AOH Sync. {% hint style="info" %} Access Management is where you administer permission groups and review role assignments. For a conceptual overview of how roles and groups work, see [Roles & Permissions](/core-concepts/roles-and-permissions). {% endhint %} ![The Access Management screen showing five system permission groups — Analyst, Enterprise Resources, Global Administrator, Security, and System Administrator — with role counts and types. The Analyst role matrix is expanded at the bottom, showing 6 of 22 system roles granted to that group.](/files/iU7jAC0dzLzwl3CfNMpm) *The Access Management screen. Select any group row to expand its role matrix. Click **View full matrix** to see all 22 system roles.* ## What you can do here | Action | What it does | | ---------------------- | --------------------------------------------------------------------------------------------------------------- | | View permission groups | See all groups, their descriptions, how many roles each includes, and whether they are System-defined or custom | | Expand the role matrix | Select a group row to see which of the 22 system roles are granted (checked) or withheld for that group | | **View full matrix** | Opens the complete 22-role grid for the selected group | | **+ Create Group** | Opens a form to define a new custom permission group with any combination of system roles | | Edit (pencil icon) | Modify the roles assigned to an existing group | ## Built-in groups AOH Sync ships with five system-defined groups that cover common organizational needs: | Group | What it grants | | ------------------------ | --------------------------------------------------------------------------------------- | | **Analyst** | Read-only access to dashboards, lifecycle data, and provisioning status — 6 roles | | **Enterprise Resources** | HR-facing access to Connectors, user lifecycle, and attribute information — 6 roles | | **Global Administrator** | Unrestricted access to all system features and administration — 22 roles | | **Security** | Audit log access, secrets management, user lock/unlock, and system monitoring — 7 roles | | **System Administrator** | System operations including configuration, Connectors, scheduling, and more — 8 roles | System-defined groups display the **System** badge. They cannot be deleted. ## How to use it {% stepper %} {% step %} **Review the existing groups** Scan the group list to confirm the built-in groups match your organization's access model. Check the role count for each group to understand its scope. {% endstep %} {% step %} **Inspect a group's role matrix** Click any group row to expand the role matrix at the bottom of the screen. Checked roles are granted; unchecked roles are withheld. Click **View full matrix** to see all 22 roles in a single view. {% endstep %} {% step %} **Create a custom group (if needed)** Click **+ Create Group** in the top-right corner. Name the group, add a description, then select the system roles to include. Save the group. {% endstep %} {% step %} **Assign users to groups** Navigate to [User Management](/administration/user-management) to assign your users to the appropriate groups. {% endstep %} {% endstepper %} ## How to create a permission group and assign roles If none of the five built-in groups match a team's exact access needs, create a custom group and compose it from the 22 system roles. {% stepper %} {% step %} **Open the group creation form** Click **+ Create Group** in the top-right corner of the Access Management screen. {% endstep %} {% step %} **Name the group and add a description** Enter a name that reflects the team or function (for example, "Helpdesk Tier 1"). Add a short description so other administrators understand the group's purpose. {% endstep %} {% step %} **Select system roles from the role matrix** Choose the system roles to include. Use the role matrix as a reference — the Analyst group shown on this page, for example, has 6 of 22 system roles granted, including Dashboard Access, Attribute Information, Provisioning Status, Reports Generation, Mover Events Access, and User Lifecycle Access. Roles that are checked are granted; unchecked roles are withheld. {% hint style="info" %} Click **View full matrix** on any existing group to see all 22 system roles and their descriptions before deciding which ones to include in your new group. {% endhint %} {% endstep %} {% step %} **Save the group** Confirm your selections to create the group. It appears in the group list with the role count you configured and a custom (non-System) type badge. {% endstep %} {% step %} **Assign users to the new group** Navigate to [User Management](/administration/user-management) to assign users to your new group. {% endstep %} {% endstepper %} ## Related * [Roles & Permissions](/core-concepts/roles-and-permissions) — concept overview of how groups and roles work * [User Management](/administration/user-management) — assign users to permission groups * [Audit & Status Logs](/administration/audit-and-status-logs) — review access-related activity # User Management Manage the users who have access to AOH Sync, control their lock status, assign them to permission groups, and administer API keys. ![The User Management screen showing the Users tab with an Application Users table. Columns include Name, Email, Group, Additional Roles, Status, Joined date, and Actions. Summary cards at the bottom show Total App Users (1, with 1 active and 0 locked) and Active API Keys (0, none expiring soon).](/files/NcaruxCSzZKzWHsbGX6j) *The User Management screen. Users are automatically registered on first login. The summary cards at the bottom show totals at a glance.* ## What you can do here | Action | What it does | | ------------------ | --------------------------------------------------------------------------------- | | **Users** tab | View all users who have logged in, their group assignments, status, and join date | | **Groups** tab | View and manage the permission groups available in your organization | | **API Keys** tab | Create and manage API keys for programmatic access to AOH Sync | | **Audit Logs** tab | Browse a log of user-level administrative actions | | **Recovery** tab | Access recovery options for locked or inaccessible accounts | | **Edit Group** | Change the permission group a user belongs to | | **Lock / Unlock** | Immediately suspend or restore a user's access to AOH Sync | | **Refresh** | Reload the user list to reflect recent logins or changes | ## Application Users Users are automatically registered the first time they log in with their organization credentials. You do not need to manually provision users — AOH Sync creates their record on first login. Each user row shows: * **Name** and **Email** — the identity used to log in * **Group** — the permission group currently assigned to the user * **Additional Roles** — any roles granted outside the group assignment * **Status** — **Active** (green) or locked * **Joined** — the date of first login ## How to use it {% stepper %} {% step %} **Find the user** Open the **Users** tab. Use the table to locate the user by name or email. Click **Refresh** if you expect a recently logged-in user to appear. {% endstep %} {% step %} **Assign or change the user's group** Click **Edit Group** in the user's row. Select the appropriate permission group and save. The user's effective permissions update immediately. {% endstep %} {% step %} **Lock a user if needed** Click **Lock** in the user's row to immediately revoke their access. A locked user cannot log in until you unlock them. Click the same button (shown as **Unlock** when locked) to restore access. {% endstep %} {% endstepper %} ## Related * [Access Management](/administration/access-management) — define and manage permission groups * [Roles & Permissions](/core-concepts/roles-and-permissions) — understand how groups and roles work * [Audit & Status Logs](/administration/audit-and-status-logs) — review activity across your organization # Vault Vault is AOH Sync's centralized store for the credentials and secrets that your Connectors use to communicate with connected systems. The Vault screen shows the store's seal state and a searchable, filterable inventory of secrets grouped by category, each with per-secret and bulk rotation actions. ## What you can do here | Action | What it does | | -------------------------------- | ---------------------------------------------------------------------------------------- | | View seal state | Confirm whether the Vault is **UNSEALED** (accessible) or sealed | | Search secrets | Use the search bar to find secrets by name, owner, or domain | | **Domain filter** | Narrow the list to secrets belonging to a specific connected system | | **Owner filter** | Filter secrets by the component or Connector that registered them | | **Rotate** (per secret) | Trigger an immediate rotation for an individual secret | | **Rotate all infra credentials** | Trigger a bulk rotation of all externally-coordinated infrastructure credentials at once | | View rotation schedule | See which secrets have upcoming rotation jobs queued and how many are pending | | **Refresh** | Reload the Vault inventory to reflect recent changes | ## Seal state The Vault displays a status badge at the top of the screen: * **UNSEALED** — the store is open and credentials are accessible to your Connectors * A sealed state would prevent Connectors from retrieving credentials The badge also shows a partial identifier of the master key and the time the Vault was last unsealed. ## Secrets inventory Secrets are grouped into categories based on how they are managed: * **EXTERNAL-COORDINATED** — credentials that are coordinated with external systems (for example, infrastructure passwords and session keys). 4 secrets are shown in this category. * **INTERNAL-ROTATABLE** — internally managed credentials that can be rotated on demand (for example, application service passwords). 11 secrets are shown in this category. Each secret row displays: **Name**, **Type**, **Cadence**, **Next Due**, **Last Rotated**, **Owner**, **Active** version, **Job** status, and a **Rotate** button in the Actions column. You can search and filter the full inventory to locate a specific credential, check its owner, or review its rotation status. ## Rotation Schedule The **Rotation Schedule** section at the bottom of the screen shows any rotation jobs that are queued. When no rotations are pending, it displays "No rotation jobs queued." AOH Sync tracks upcoming rotations so credentials are kept current without manual intervention. {% hint style="info" %} Vault access is controlled by the **Vault Admin**, **Vault Operator**, and **Vault Reader** roles in your permission groups. Only users with the appropriate role can view or manage secrets. See [Access Management](/administration/access-management) to review role assignments. {% endhint %} ## Related * [Access Management](/administration/access-management) — control who can view and manage Vault secrets * [Connectors](/feature-reference/connectors) — Connectors register and use credentials stored in the Vault * [System Settings](/administration/system-settings) — view overall system health alongside Vault status # System Settings Review your license, monitor overall system health, and manage integration and display configuration for your AOH Sync instance. ![The System Settings screen showing the Maintenance tab. A License card displays the license type (standard), a License ID, active user count (1,531 of 19,999 entitled), max users (19,999), utilization percentage (8%), expiry (Never), and an Upload button. Below, an Event Health — 30 days chart shows 28% Success (17 events), 0% Failed (0 events), and 72% Info (43 events) across 60 total events. A System Overview section is visible at the bottom, showing a Service health card (All running), a Health check card (Passing), a Disk usage card (60% used), a Restart Service card for restarting individual containers, and an Update Images card for force re-pulling all container images.](/files/pVNFcDNWBXfhDoLeggGi) *System Settings — Maintenance tab. The License card and Event Health chart give a quick read on capacity and operational health.* ## Tabs | Tab | What it shows | | ---------------- | ------------------------------------------------------------------------ | | **Maintenance** | License details, event health over the last 30 days, and system overview | | **Integrations** | Configuration for connected integrations | | **SSL** | SSL certificate settings | | **Branding** | Display and branding customization | ## Maintenance tab ### License The License card shows: * **License type** — for example, **standard** * **License ID** — a unique identifier you can copy to share with support * **Active users** — how many users are currently active against your entitlement * **Max users** — the maximum number of users your license permits * **Utilization** — the percentage of your licensed capacity in use * **Expires** — the license expiry date (**Never** for perpetual licenses) * **Features** — any additional licensed feature flags * **Upload** — replace or update your license file ### Event Health — 30 days This chart summarizes all sync events over the past 30 days across your organization: | Category | Meaning | | ----------- | --------------------------------------------- | | **Success** | Events that completed without error | | **Failed** | Events that encountered an error | | **Info** | Informational events, such as skipped records | The total event count and percentage breakdown are shown alongside a horizontal bar chart for quick visual reference. ### System Overview The System Overview section below the Event Health chart displays real-time health indicators for key components of your instance. It includes the following cards: | Card | What it shows | | ------------------- | ------------------------------------------------------------------------------------------------------ | | **Service health** | Status of each internal component — shows **All running** when everything is operational | | **Health check** | Result of automated health checks — shows **Passing** when all checks succeed | | **Disk usage** | Current disk utilization on your instance (for example, 60% used) | | **Restart Service** | Lets you restart a single container — select the target from the dropdown and confirm | | **Update Images** | Forces a re-pull of all container images to their latest versions — click **Update Images** to trigger | ## How to use it {% stepper %} {% step %} **Check license utilization** Open **System Settings** and confirm the active user count is within your entitled limit. If utilization is approaching capacity, contact your account team before onboarding additional users. {% endstep %} {% step %} **Copy your License ID for support requests** Click **Copy** next to the License ID to copy it to your clipboard. Include it in any support request so the team can identify your instance quickly. {% endstep %} {% step %} **Upload a new license** If you have received an updated license file, click **Upload** in the License card and select the file. The new entitlements take effect immediately. {% endstep %} {% endstepper %} ## Related * [Audit & Status Logs](/administration/audit-and-status-logs) — live operational status for your pipelines * [User Management](/administration/user-management) — manage the users counted against your license * [Getting Started — Managing Your Instance](/getting-started/11-managing-your-instance) — update and maintenance procedures for your AOH Sync instance # Notifications The Notifications page is where you manage email notification templates, delivery schedules, and send logs for your AOH Sync environment. ![The Notifications page showing a "Notification server — 404 page not found" banner with an Unreachable status badge, three tabs (Templates, Schedules, Logs), and a Templates panel listing example template cards](/files/S4wmYH9JarvOUOP6bude) *The Notifications page with three tabs: Templates, Schedules, and Logs. The notification server status banner appears at the top of the page.* {% hint style="warning" %} If the notification server is unavailable, a status banner at the top of the page shows **Unreachable**. Templates and schedules are still visible, but email delivery is paused until the server is reachable again. {% endhint %} ## What you can do here | Action | What it does | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Templates tab** | View and search the global email templates available across your notification server. Templates are created and edited by administrators on the notification server. | | **Schedules tab** | | | **Logs tab** | | | Search templates | Use the search box on the Templates tab to find a template by name or slug. | ## How to use it {% stepper %} {% step %} **Check server status** Confirm the notification server status banner at the top of the page shows no error. If the server is **Unreachable**, contact your administrator — email delivery is paused until the server is available again. {% endstep %} {% step %} **Review the available templates** Open the **Templates** tab to see the email templates configured for your environment. Each template card shows its name and a preview of the email body. Templates are created and edited by administrators on the notification server — contact your administrator if a template needs to be added or changed. {% endstep %} {% step %} **Review schedules and logs** Use the **Schedules** tab to confirm when notifications are set to send, and the **Logs** tab to verify recent delivery history. {% endstep %} {% endstepper %} ## Related * [System Settings](/administration/system-settings) * [Audit & Status Logs](/administration/audit-and-status-logs) * [User Management](/administration/user-management) # Audit & Status Logs The **Status & Logs** screen (shown in the navigation as *Audit & Status Logs*) gives you a live view of the operational state of all your pipelines in one place, updated in real time. ![The Status & Logs screen showing four summary cards: Pipelines (6, with 0 healthy, 6 degraded, 0 failed per the card counters), Last 24H Success (100.0%, 284 succeeded, 0 failed), DLQ Depth (0), and Avg Run Duration (7s across 264 runs in the last 24 hours). A green "All pipelines healthy" banner appears below the cards. The Pipelines section lists six connector pipelines — Bamboo, GitHub, Okta, Slack, WorkDay, and AOH Test AD — each showing an OK status badge, with last-run and sync-count details. Filter buttons (All, Failed, Partial, OK) are visible.](/files/EL5KNFBBashtUA1E9vBR) *The Status & Logs screen, live-refreshed. The summary cards give an at-a-glance read of overall pipeline health.* ## Summary cards | Card | What it shows | | -------------------- | ----------------------------------------------------------------------------------------------------------- | | **Pipelines** | Total number of pipelines, broken down by healthy, degraded, and failed | | **Last 24H Success** | Percentage of runs that succeeded in the last 24 hours, with raw succeeded and failed counts | | **DLQ Depth** | The number of items waiting to be reprocessed — a non-zero value may indicate a problem worth investigating | | **Avg Run Duration** | Average time per run across all pipelines in the last 24 hours | ## Pipelines list Below the summary cards, each active pipeline is listed as a tile. Each tile shows: * **Pipeline name** — the Connector feeding into AOH Sync (for example, "Bamboo → AOH Sync") * **Status badge** — **OK**, **Partial**, or **Failed** * **Last run** and **records synced** count Use the **Filter** buttons (**All**, **Failed**, **Partial**, **OK**) to narrow the list to pipelines in a particular state. {% hint style="info" %} The screen header shows **Live · refreshed Xs ago**, confirming data is current. No manual refresh is needed during normal monitoring. {% endhint %} ## What to do when a pipeline shows a problem {% stepper %} {% step %} **Identify the affected pipeline** Use the **Failed** or **Partial** filter to isolate pipelines that are not fully healthy. Note the pipeline name and last-run timestamp. {% endstep %} {% step %} **Check the DLQ Depth card** A depth greater than zero means records are queued for reprocessing. If the depth is growing, investigate the corresponding Connector. {% endstep %} {% step %} **Review the Connector** Navigate to the [Connectors](/feature-reference/connectors) section, open the relevant Connector, and check its sync history for error details. {% endstep %} {% step %} **Contact support if needed** If the issue persists, gather the pipeline name, last-run time, and any error messages, then open a support request. {% endstep %} {% endstepper %} ## The audit trail: decisions, not just changes AOH Sync records more than state changes — it records reviewed decisions too. When an orphaned account is dismissed, when an anomaly is acknowledged, or when a machine identity ownership transfer occurs, the action and the person who took it are logged. This means "we knew and decided" is never confused with "we never noticed": both deliberate choices and automated changes appear as attributable entries. ## Related * [Connectors — Sync History](/feature-reference/connectors/logs) — per-Connector run logs and error details * [System Settings](/administration/system-settings) — event health summary over the last 30 days * [Action Center](/feature-reference/data-quality) — review and resolve data quality issues flagged during syncs * [Roles & Permissions](/core-concepts/roles-and-permissions) — how access changes are authorized and recorded # User Settings Manage your personal notification preferences, display options, and API keys for your AOH Sync account. ![The User Settings screen showing the Preferences tab. Under Notifications, two toggles are visible: Email Notifications (enabled) and In-App Alerts (enabled). Under Display, Compact Mode (disabled) and Use Browser Timezone (enabled) are shown.](/files/HVJPpjArsUTpxvPCiQbL) *User Settings — Preferences tab. Changes take effect immediately without a page reload.* ## Tabs | Tab | What it contains | | --------------- | -------------------------------------------------- | | **Preferences** | Notification delivery options and display settings | | **API Keys** | Personal API keys for accessing the AOH Sync API | ## Preferences tab ### Notifications | Setting | What it controls | | ----------------------- | --------------------------------------------------------------------- | | **Email Notifications** | When enabled, AOH Sync sends updates to your registered email address | | **In-App Alerts** | When enabled, notifications appear inside the AOH Sync interface | ### Display | Setting | What it controls | | ------------------------ | ------------------------------------------------------------------------------- | | **Compact Mode** | When enabled, tables use a condensed layout to show more rows on screen | | **Use Browser Timezone** | When enabled, all timestamps in AOH Sync display in your local browser timezone | ## API Keys tab The **API Keys** tab lets you create personal API keys to authenticate your own requests to the AOH Sync API. API keys created here are scoped to your user account and carry your effective permissions. {% hint style="info" %} For organization-level API keys used by automated processes, see the **API Keys** tab in [User Management](/administration/user-management). Personal keys in User Settings are for individual use only. {% endhint %} ## Related * [User Management](/administration/user-management) — manage organization-wide users and API keys * [Access Management](/administration/access-management) — manage permission groups and role assignments * [Audit & Status Logs](/administration/audit-and-status-logs) — monitor live pipeline health and sync activity # API Overview & Authentication The AOH Sync Public API gives you programmatic access to your tenant's identity data, sync operations, and webhook subscriptions. You can query identities and users, trigger sync jobs, and receive real-time event notifications — all scoped to your tenant. ## Base URL The base URL for the Public API is environment-specific — it depends on how your AOH Sync instance is deployed and exposed. All endpoints are versioned under `/v1/`. The `/v1/health` endpoint is unauthenticated; every other endpoint requires an API key. ## Authentication Every authenticated request must include your API key in the `X-API-Key` request header: ```http GET /v1/identities HTTP/1.1 X-API-Key: your-api-key-here ``` There is no other authentication method for the Public API. Requests that omit the header, or that supply an invalid key, receive a `401 Unauthorized` response. ## Tenant scoping Your API key is bound to your AOH Sync tenant. All data returned by the API — identities, users, sync jobs, webhooks — belongs to that tenant only. You cannot query data from other tenants. ## How to obtain an API key Store your key securely. Treat it like a password — it grants full read/write access to your tenant's API surface. ## Making a request Here is a minimal example using `curl` to list identities: ```bash curl -s \ -H "X-API-Key: your-api-key-here" \ "https:///v1/identities?limit=10" ``` A successful response includes a `data` array, plus pagination fields (`total`, `limit`, `offset`): ```json { "data": [ ... ], "total": 142, "limit": 10, "offset": 0 } ``` ## Pagination List endpoints (`/v1/identities`, `/v1/users`) support `limit` and `offset` query parameters. The default page size is 50. Use `offset` to step through large result sets. | Parameter | Type | Default | Description | | --------- | ------- | ------- | --------------------------- | | `limit` | integer | 50 | Number of results to return | | `offset` | integer | 0 | Number of results to skip | ## Related * [Public API Reference](/developer-and-api/reference) * [Webhooks](/developer-and-api/webhooks) * [Errors & Rate Limits](/developer-and-api/errors-and-rate-limits) # Public API Reference Complete reference for all AOH Sync Public API endpoints. Every endpoint under `/v1/` (except `/v1/health`) requires the `X-API-Key` header. ## Interactive reference {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/health" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/identities" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/identities/{id}" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/identities/{id}/history" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/users" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/users/{id}" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/sync/trigger" method="post" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/sync/jobs/{id}" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/webhooks" method="post" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/webhooks" method="get" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/webhooks/{id}" method="patch" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/webhooks/{id}" method="delete" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} {% openapi src="/files/tO4eNBkQtZAeK7gPbHpf" path="/v1/webhooks/{id}/rotate-secret" method="post" %} [openapi.yaml](https://2706226485-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8BF8xXbTZGWilkpjaGNh%2Fuploads%2Fgit-blob-2e867d3d1f88c355d16fd9ddcb07178ae10124ea%2Fopenapi.yaml?alt=media) {% endopenapi %} *** ## Endpoint summary The table below is always readable, regardless of how the interactive blocks are configured. | Method | Path | Summary | Auth required | | -------- | --------------------------------- | --------------------------------------- | ------------- | | `GET` | `/v1/health` | Health check | No | | `GET` | `/v1/identities` | List identities (paginated) | Yes | | `GET` | `/v1/identities/{id}` | Get a single identity by ID | Yes | | `GET` | `/v1/identities/{id}/history` | Get lifecycle history for an identity | Yes | | `GET` | `/v1/users` | List users for the caller's tenant | Yes | | `GET` | `/v1/users/{id}` | Get a single user by ID | Yes | | `POST` | `/v1/sync/trigger` | Trigger a sync job for a connector | Yes | | `GET` | `/v1/sync/jobs/{id}` | Get sync job status | Yes | | `POST` | `/v1/webhooks` | Create a webhook subscription | Yes | | `GET` | `/v1/webhooks` | List webhook subscriptions | Yes | | `PATCH` | `/v1/webhooks/{id}` | Update a webhook subscription | Yes | | `DELETE` | `/v1/webhooks/{id}` | Delete a webhook subscription | Yes | | `POST` | `/v1/webhooks/{id}/rotate-secret` | Rotate the signing secret for a webhook | Yes | ## Key schemas ### Identity An Identity is AOH Sync's unified representation of a person, combining attributes, linked user accounts, directory accounts, and machine identities. ```json { "id": "idty_01abc", "display_name": "Alex Johnson", "status": "active", "created_at": "2025-01-15T09:00:00Z", "updated_at": "2025-06-01T14:22:00Z", "attributes": [ { "identity_id": "idty_01abc", "field_name": "department", "field_value": "Engineering", "source_type": "hr", "source_id": "src_hr01", "priority": 1, "updated_at": "2025-06-01T14:22:00Z" } ], "users": [ ... ], "accounts": [ ... ], "machine_identities": [ ... ] } ``` ### User A User is a directory record (e.g. from Microsoft Entra) linked to an Identity. Users belong to the caller's tenant. ```json { "id": "usr_01xyz", "external_id": "aad-object-id", "user_principal_name": "alex@contoso.com", "display_name": "Alex Johnson", "email": "alex@contoso.com", "job_title": "Staff Engineer", "status": "active", "tenant_id": "tenant_01", "hire_date": "2022-03-01T00:00:00Z", "roles": ["reader"], "groups": ["engineering"], "departments": ["Engineering"] } ``` ### SyncJob (trigger response) ```json { "job_id": "job_01def", "status": "queued" } ``` ### SyncStatus (job status response) ```json { "job_id": "job_01def", "status": "running", "progress_pct": 42, "started_at": "2025-07-21T10:00:00Z", "completed_at": null, "error_message": null, "batches_processed": 5, "batches_total": 12 } ``` ## Related * [API Overview & Authentication](/developer-and-api/developer-api) * [Webhooks](/developer-and-api/webhooks) * [Errors & Rate Limits](/developer-and-api/errors-and-rate-limits) # Webhooks Webhooks let AOH Sync push real-time event notifications to your own infrastructure. When something changes in your tenant — a sync completes, an identity is modified — AOH Sync sends an HTTP POST to your configured endpoint. ## Subscription model A webhook subscription consists of: | Field | Type | Description | | -------------- | --------- | -------------------------------------------------------- | | `id` | string | Unique identifier for the subscription | | `callback_url` | URI | The HTTPS endpoint AOH Sync sends events to | | `events` | string\[] | Event types this subscription listens for (at least one) | | `active` | boolean | Whether the subscription is currently delivering events | | `created_at` | datetime | When the subscription was created | When you create a subscription, the response also includes a one-time `signing_secret`. Store this immediately — it is never returned again. ## Create a subscription ```http POST /v1/webhooks X-API-Key: your-api-key-here Content-Type: application/json { "callback_url": "https://your-server.example.com/cloudsync/events", "events": ["sync.completed", "identity.updated"] } ``` **Response (201 Created):** ```json { "id": "wh_01abc", "callback_url": "https://your-server.example.com/cloudsync/events", "events": ["sync.completed", "identity.updated"], "active": true, "created_at": "2025-07-21T10:00:00Z", "signing_secret": "whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } ``` {% hint style="warning" %} The `signing_secret` is returned only once, at creation time. If you lose it, rotate the secret using the `/v1/webhooks/{id}/rotate-secret` endpoint. {% endhint %} ## List subscriptions ```http GET /v1/webhooks X-API-Key: your-api-key-here ``` **Response (200 OK):** ```json { "data": [ { "id": "wh_01abc", "callback_url": "https://your-server.example.com/cloudsync/events", "events": ["sync.completed", "identity.updated"], "active": true, "created_at": "2025-07-21T10:00:00Z" } ], "total": 1 } ``` The `signing_secret` is not included in list or update responses — only in the create and rotate-secret responses. ## Update a subscription Use `PATCH /v1/webhooks/{id}` to change the callback URL, event list, or active state. All fields are optional; only the ones you send are updated. ```http PATCH /v1/webhooks/wh_01abc X-API-Key: your-api-key-here Content-Type: application/json { "active": false } ``` **Response (200 OK):** Returns the updated `Webhook` object (without `signing_secret`). To re-enable a paused subscription, send `"active": true`. ## Delete a subscription ```http DELETE /v1/webhooks/wh_01abc X-API-Key: your-api-key-here ``` **Response:** `204 No Content`. The subscription is removed and AOH Sync stops delivering events to that endpoint. ## Signing secret & verification Every event delivery is signed with HMAC-SHA256 using your subscription's `signing_secret`. Verify the signature on every incoming request to confirm it came from AOH Sync and was not tampered with. ## Secret rotation If your signing secret is compromised, rotate it without deleting and recreating the subscription: ```http POST /v1/webhooks/wh_01abc/rotate-secret X-API-Key: your-api-key-here ``` **Response (200 OK):** ```json { "signing_secret": "whsec_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy" } ``` {% hint style="warning" %} The new `signing_secret` is returned only once. Update your verification logic immediately — the old secret stops working as soon as the new one is issued. {% endhint %} ## Event delivery AOH Sync sends a `POST` request to your `callback_url` for each event the subscription is configured to receive. Your endpoint must return a `2xx` status code to acknowledge receipt. ## Related * [API Overview & Authentication](/developer-and-api/developer-api) * [Public API Reference](/developer-and-api/reference) * [Errors & Rate Limits](/developer-and-api/errors-and-rate-limits) # Errors & Rate Limits ## Error format All API errors return a JSON body with a single `error` field describing what went wrong: ```json { "error": "missing or invalid API key" } ``` The HTTP status code tells you the category of error; the `error` string gives the specifics. ## HTTP status codes | Status code | Meaning | | ----------- | ----------------------------------------------------------------------- | | `200` | Request succeeded. | | `201` | Resource created (e.g. webhook subscription). | | `202` | Request accepted for asynchronous processing (e.g. sync job triggered). | | `204` | Resource deleted — no response body. | | `400` | Bad request — the request body is missing required fields or malformed. | | `401` | Missing or invalid `X-API-Key` header. | | `404` | The requested resource does not exist. | | `500` | Internal server error — something went wrong on AOH Sync's side. | ## Common error scenarios ### 401 — Missing or invalid API key This is returned whenever the `X-API-Key` header is absent or the key is not recognised. The `/v1/health` endpoint is the only route that does not require a key. ```bash curl -s "https://api.cloudsync.io/v1/identities" # → 401 {"error":"missing or invalid API key"} ``` ### 400 — Bad request Returned when a required field is missing from a request body or a value is invalid. For example, calling `POST /v1/webhooks` without a `callback_url` or `events` array returns 400. ```json { "error": "callback_url is required" } ``` ### 404 — Not found Returned when you reference an ID that does not exist in your tenant, or that belongs to a different tenant. ### 500 — Internal error These are unexpected server-side failures. If you receive repeated 500 responses, contact AOH Sync support with the request details and timestamp. ## Rate limits ## Related * [API Overview & Authentication](/developer-and-api/developer-api) * [Public API Reference](/developer-and-api/reference) * [Webhooks](/developer-and-api/webhooks) # 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: | Component | What it represents | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **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 | Purpose | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `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: ``` Source --[USER_OF]--> User Source --[SOURCE_OF]--> Group Source --[DEPARTMENT_OF]--> Department User --[MEMBER_OF]--> Group User --[WORKS_IN]--> Department User --[CAUSED]--> IdentityLifecycleEvent Department --[CONTAINS]--> Group IdentityLifecycleEvent --[NEXT]--> IdentityLifecycleEvent ``` 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: ``` Conflict Source Systems Normalization Resolution Target (Entra) -------------------------------------------------------------------- +-----------+ HR System ──────────┐ | | │ +-----------+ | Identity | SCIM Bulk Azure AD (source) ──┼──>| Ingest & |->| Attribute |->Upload ──> Entra ID │ | Normalize | | Priority | SQL / REST ─────────┘ +-----------+ | Merge | +-----------+ Neo4j Redis Graph API Identity Graph Cache ``` **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: | Event type | Meaning | | ---------- | ----------------------------------------------------------------------------- | | `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 * [What Data AOH Sync Stores](/trust-security-and-data-handling/what-data-we-store) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency) * [Encryption](/trust-security-and-data-handling/encryption) * [Microsoft Entra Permissions Requested](/trust-security-and-data-handling/entra-permissions) # What Data AOH Sync Stores AOH Sync stores only the identity data it needs to normalize your connected sources and provision your Microsoft Entra ID tenant. This page describes each category of data, what it contains, and why AOH Sync holds it. *** ## Categories of data ### People records (Users) For each person in a connected Source System, AOH Sync stores: * Core profile: display name, first name, last name, email address, user principal name * Job attributes: job title, department * Account status (active, disabled, or similar) * Hire date * Group and role memberships (which groups and roles this person holds) * Department memberships (which organizational units this person belongs to) * A timestamp recording when the record was last synchronized AOH Sync does not store passwords, authentication credentials, or any sensitive personal data beyond what is needed for identity provisioning. ### Accounts For each directory or application account linked to a person, AOH Sync stores: * An internal identifier and an external identifier from the source system * The account's `identifier` (for example, a UPN or username) * Display name and basic profile fields (first name, last name, job title) * Account status * Which Source System this account came from (`source_system_id`) * Which Identity this account belongs to (`person_id`) * Timestamps for creation, last update, and last synchronization ### Machine Identities For non-human principals (service accounts, shared mailboxes, robot users) that are associated with a person or an Identity, AOH Sync stores: * Display name and classification * Ownership references: who owns this account (`owned_by`), the account's manager (`manager_id`), and who inherits technical responsibility (`technical_inheritor`) * Status and a computed risk score * Timestamps for creation and last update ### Identity Attributes For each resolved attribute on an Identity (for example, the authoritative job title), AOH Sync stores: * The field name and the resolved value * The source that supplied the winning value (`source_type`, `source_id`) * The priority used to select this value over competing values * The timestamp when this attribute was last updated See [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane) for a detailed explanation of how attributes are resolved across multiple sources. ### Lifecycle events AOH Sync records joiner, mover, and leaver events for every identity. Each event stores: * Event type (`joiner`, `mover`, or `leaver`) * The identity the event is associated with * A timestamp * A structured details payload describing what changed These events form an audit-quality timeline of identity activity across your environment. ### Synchronization history and logs AOH Sync retains logs of each synchronization run, including: * Which connector ran and when * Counts of users and groups processed, succeeded, skipped, or failed * Any errors encountered during provisioning, including the affected attribute and the error message * Provisioning log entries sourced from Microsoft Entra ID's own audit logs (via `auditLogs/provisioning`) Each domain directory sync log record is stamped with an `expires_at` value set to 90 days after it is written (this is the default configured in the database schema). Records past their `expires_at` date are eligible for cleanup. ### Configuration data AOH Sync stores the configuration you enter when setting up connectors and Entra targets: * Source System connection settings (connection type, endpoint, resource definitions) * Provisioning configuration per Entra target (tenant ID, service principal, job ID, attribute mappings, mode) * Scheduled job definitions (cron expressions, job type) * Email notification settings * User preferences Credentials (client secrets, database passwords, API keys for source connectors) are **not** stored in the main configuration tables. They are stored in the Vault — see [Encryption](/trust-security-and-data-handling/encryption) for how credentials are protected. ### Controlled Entra tenant registrations For each Entra ID tenant AOH Sync provisions, it stores: * Tenant ID and client ID of the service principal used for provisioning * The service principal ID and the SCIM bulk job ID * The name of the secret in the Vault that holds the credentials for this tenant * Region, enabled status, and timestamps *** ## What AOH Sync does not store * Passwords or authentication credentials for your users * The content of emails, files, or any user-generated content from your systems * Payment or billing information (handled by the license server, which is a separate service) * Personally identifiable data beyond what is enumerated above *** ## Related * [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency) * [Encryption](/trust-security-and-data-handling/encryption) * [Data Retention & Deletion](/trust-security-and-data-handling/retention-and-deletion) # Where Your Data Lives AOH Sync is deployed as a **single-tenant virtual machine in your own Azure subscription**. AOH Sync runs entirely inside your own Azure subscription. Your identity data is not sent to the AOH Sync vendor's infrastructure — the only outbound connections are to the Microsoft endpoints and services listed below (and are required for AOH Sync to function). *** ## Single-tenant deployment model When you deploy AOH Sync from the Azure Marketplace, the installation creates all required resources inside the Azure subscription and resource group you control. There is no multi-tenant SaaS backend operated by the AOH Sync vendor that receives or retains copies of your identity data. The complete set of data stores — the identity graph, the relational configuration database, the in-memory cache, and the secret store — run as containers on that VM. All data is written to, read from, and retained on infrastructure that belongs to your subscription. *** ## What runs in your subscription | Component | Location | Purpose | | ------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AOH Sync API | Your Azure VM | Core application logic; reads sources, normalizes identities, provisions Entra | | AOH Sync web UI | Your Azure VM | Browser interface for administrators | | Identity graph database | Your Azure VM | Stores User, Group, Department, Source, and IdentityLifecycleEvent nodes and their relationships | | Configuration database | Your Azure VM | Stores connector configs, provisioning configs, scheduled jobs, sync logs | | In-memory cache | Your Azure VM | Caches live identity data from your source Azure AD and accelerates queries; no data persists if the cache restarts without an explicit persistence configuration | | Vault service | Your Azure VM | Stores connector credentials and other secrets, envelope-encrypted; see [Encryption](/trust-security-and-data-handling/encryption) | | Reverse proxy / TLS termination | Your Azure VM | Terminates HTTPS connections; handles certificate management | | Telemetry collector | Your Azure VM | Collects internal observability signals; | *** ## Outbound connections your VM makes AOH Sync makes outbound HTTPS connections from your VM to the following external endpoints: | Destination | Purpose | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Microsoft Graph API (`graph.microsoft.com`) | Reading identity data from your source Azure AD tenants; provisioning to your target Entra ID tenant | | Microsoft Entra ID token endpoints | Authenticating users (OIDC) and obtaining service tokens for Graph API calls | | Azure Container Registry (ACR) | Pulling updated container images during upgrades | | Azure Blob Storage (onboarding only) | Fetching deployment manifests and compose files during initial installation and upgrades | | AOH Sync license server | Validating your license at startup and periodically thereafter | Microsoft Graph API calls go directly from your VM to Microsoft's endpoints using credentials that you configure in your subscription — no identity data passes through the AOH Sync vendor for those calls. The license server connection is designed to transmit only license key and usage-count metadata, not identity-plane data; however, this has not been independently verified for all flows. *** ## Data sovereignty implications Because all identity data is stored on your VM in your Azure subscription, data residency is determined by the Azure region you selected when deploying the VM. If your organization requires data to remain within a specific geographic region (for example, within the EU or within the United States), you control that by choosing the appropriate Azure region at deployment time. AOH Sync does not impose any geographic restriction or routing that would cause your identity data to pass through a region other than the one where your VM is located. *** ## Related * [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane) * [What Data AOH Sync Stores](/trust-security-and-data-handling/what-data-we-store) * [Encryption](/trust-security-and-data-handling/encryption) # Encryption AOH Sync protects your data in transit with TLS and protects credentials at rest using an in-house secret store (the Vault). This page describes what is protected, how it is protected, and what to confirm with your deployment team for compliance purposes. *** ## Data in transit All HTTP traffic to and from the AOH Sync web interface and API is carried over **HTTPS (TLS)**. A reverse proxy (Caddy) runs as a dedicated container on the VM and handles TLS termination before any request reaches the application. Caddy's TLS configuration (certificate source, minimum TLS version, cipher suite selection) is controlled by your deployment configuration. Connections to Microsoft Graph, Entra ID, the container registry, and the license server are made over HTTPS. Internal communication between containers on the same VM uses localhost network interfaces. *** ## Credentials and secrets at rest: the Vault AOH Sync does not store credentials in its configuration database. Instead, every secret — database passwords, Azure client secrets for Entra provisioning, connector credentials, internal signing keys — is stored in the **Vault**, which is a dedicated secret-storage service running on the same VM. The Vault uses **envelope encryption**: each secret is encrypted under a per-domain key-encryption key (KEK), and KEKs are themselves protected by a root key. This means: * Connector credentials and Entra client secrets are encrypted before they are written to the Vault's storage. * The application retrieves a live credential from the Vault at startup and refreshes it on a half-TTL cadence; credentials are not stored in memory longer than needed. * The Vault supports key rotation: a `VERSION_ACTIVATED` event is streamed to subscribers when a secret is rotated, allowing the application to pick up new credentials without a restart. * A two-person break-glass workflow is available for high-value secrets via the Vault's checkout/checkin mechanism. * Operator-level Vault administration (KEK rotation, seal state, audit query) is restricted to authorized operators. *** ## Database encryption at rest AOH Sync's identity graph, relational configuration database, and in-memory cache run as containers on your Azure VM. Azure VM disks can be protected with Azure Disk Encryption, which is a platform-level control available in every Azure subscription. Whether this is enabled for your AOH Sync VM is determined by your deployment configuration and your organization's Azure policy. *** ## API authentication Access to the AOH Sync API requires one of: * A session cookie obtained after authenticating via Microsoft Entra ID (OIDC) * A short-lived JWT bearer token * An API key (for integration consumers using the public API) API keys are stored as hashed values — the plaintext key is shown only once at creation time and is not recoverable from the stored hash. JWT signing keys are stored in the Vault, not in the configuration database. *** ## Related * [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency) * [What Data AOH Sync Stores](/trust-security-and-data-handling/what-data-we-store) # Microsoft Entra Permissions Requested AOH Sync requires a Microsoft Entra App Registration in your tenant to authenticate your administrators. This page lists every Microsoft Graph permission the App Registration requests, the permission type, and why AOH Sync needs it. *** ## How AOH Sync uses the App Registration The App Registration is used exclusively for **user authentication** — letting your Entra ID administrators sign in to the AOH Sync web interface via the standard Microsoft OIDC login flow. AOH Sync exchanges the authorization code for identity claims (email, name, user object ID, roles, tenant ID) and then creates a session for the user. The App Registration is **not** the credential AOH Sync uses to read from your source Azure AD or to provision your target Entra ID tenant. That provisioning credential is a separate service principal with its own configuration, set up during the provisioning wizard. *** ## Permissions the App Registration requests The following four delegated permissions are added to the App Registration during [Step 1 — App Registration](/getting-started/02-app-registration): | Permission | Type | Why AOH Sync needs it | | ----------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `email` | Delegated | AOH Sync reads the signed-in user's email address to populate the user session and display it in the interface. | | `openid` | Delegated | Required by the OpenID Connect protocol to initiate a sign-in and receive an ID token. Without this permission the login flow cannot complete. | | `profile` | Delegated | AOH Sync reads the user's basic profile (display name, given name, surname) from the ID token to identify who is signed in. | | `User.Read` | Delegated | Allows the signed-in user to read their own profile from Microsoft Graph, which AOH Sync uses to confirm the authenticated identity and populate session claims. | All four permissions are **delegated** (not application permissions). This means they operate in the context of the signed-in user — AOH Sync cannot use them to read other users' data without an interactive login from that user. *** ## Admin consent requirement These permissions require **admin consent** to be granted for your organization before they take effect. The App Registration setup step includes granting admin consent via the Azure Portal. Once granted, your users can sign in to AOH Sync without being individually prompted. {% hint style="info" %} All four permissions are read-only and scoped to the signed-in user. AOH Sync does not request write access to your directory via this App Registration. {% endhint %} *** ## Permissions AOH Sync does not request via the App Registration AOH Sync does not request any of the following via the App Registration used for user authentication: * Application permissions (permissions that operate without a signed-in user) * Directory read or write permissions (`Directory.Read.All`, `Directory.ReadWrite.All`) * Group read or write permissions * Any permissions beyond the four listed above Provisioning-related permissions — required to read your source directory and write to your target Entra tenant — are configured separately as part of the provisioning setup and are scoped to the specific service principal you create for that purpose. *** ## Related * [Step 1 — App Registration](/getting-started/02-app-registration) * [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency) # Data Retention & Deletion This page describes how long AOH Sync retains different categories of data and what happens to identity data when a connector is removed or a user is deprovisioned. *** ## Retention by data category ### Synchronization logs Domain directory sync logs are stored with a **90-day expiry stamp**. Each log record is written with an `expires_at` timestamp set to 90 days after the record is created. Records past their `expires_at` date are eligible for cleanup. ### Identity lifecycle events Lifecycle events (joiner, mover, leaver) are stored in both the identity graph and the relational event store. No automatic expiry is configured for lifecycle events in the sources reviewed. ### Identity graph data (Users, Groups, Departments, Sources) Identity graph nodes and edges represent the current state of your connected sources. When a sync run removes a User from all sources (for example, because the person no longer exists in any connected system), AOH Sync updates the graph accordingly. The mechanics of hard deletion vs. soft deactivation for graph nodes are: ### Configuration data Provisioning configurations, attribute mappings, scheduled jobs, and connector definitions are retained as long as they exist in the AOH Sync configuration. Deleting a connector or an Entra provisioning target removes its configuration record. ### Vault secrets Secrets stored in the Vault are retained until explicitly deleted or rotated. When a connector or Entra target is deleted, the associated secret in the Vault should be removed as part of the offboarding process. *** ## Deprovisioning: what happens when a user leaves When AOH Sync detects that an identity has been removed from or disabled in all connected Source Systems, it records a **leaver** lifecycle event and updates the identity's status. The provisioning engine then applies the configured leaver action to the target Entra ID tenant (for example, disabling the account or removing group memberships). *** ## Removing a connector When you delete a Source System connector from AOH Sync: 1. The connector's configuration record is removed from the configuration database. 2. Subsequent sync runs no longer pull data from that source. 3. Identity data that was sourced exclusively from that connector remains in the identity graph until a sync reconciliation determines it is no longer present in any remaining source. *** ## Data deletion upon license termination Because AOH Sync runs entirely within your Azure subscription, you retain control of the VM and its storage at all times. You can delete all AOH Sync data by deleting the VM and its attached disks from your Azure subscription. *** ## Related * [What Data AOH Sync Stores](/trust-security-and-data-handling/what-data-we-store) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency) * [Encryption](/trust-security-and-data-handling/encryption) # Troubleshooting Symptoms, likely causes, and steps to resolve the most common AOH Sync issues. If you work through these steps and the issue persists, contact support at ****. Include the error message, the Connector name, and when the issue started. *** ## Sync is not running **Symptoms:** The Dashboard shows no recent Sync activity; the last Sync timestamp is old; a scheduled Sync time has passed with no result. {% stepper %} {% step %} **Check whether the schedule is paused** Go to **Connectors** → your Connector → **Schedule**. If the schedule shows a paused state, resume it using the menu next to the schedule. {% endstep %} {% step %} **Check for a stuck Sync** AOH Sync will not start a new Sync while one is already running. Go to your Connector's **Sync History** and check whether a job has been running unusually long. If it appears stuck, you can cancel it and trigger a fresh Sync. {% endstep %} {% step %} **Verify the Connector is enabled** Go to **Connectors** → your Connector → **Settings** and confirm the Connector is active. {% endstep %} {% step %} **Contact support if none of the above resolves it** Email with the Connector name and the last known successful Sync time. {% endstep %} {% endstepper %} *** ## A new employee is not appearing in Entra ID **Symptoms:** A newly hired employee exists in the HR system but is not in Entra ID after the Sync has run. {% stepper %} {% step %} **Confirm the Sync has run since the employee was added to HR** Check the Connector's **Sync History** to see when the last Sync completed. If it has not run since the hire date, wait for the next scheduled Sync or trigger one manually. {% endstep %} {% step %} **Check for missing required fields** Open the Sync log and search for the employee's name or email. A skip entry will show the reason. The most common causes are a missing work email address, missing first or last name, or missing employee ID. Correct the missing data in your HR system and re-run the Sync. {% endstep %} {% step %} **Check the employee's start date** Some Connector configurations exclude employees whose start date is in the future. If the employee has a future start date, they may sync automatically when that date arrives. {% endstep %} {% step %} **Check Sync scope rules** Go to your Connector's **Settings** and review any scope filters. The employee's department, location, or employment type may be excluded from Sync. {% endstep %} {% endstepper %} *** ## Users are not updating in Entra ID after an HR change **Symptoms:** An employee changed departments, job titles, or managers in the HR system, but Entra ID still shows the old values. {% stepper %} {% step %} **Confirm the change has synced** Check the Connector's **Sync History** for a Sync run that occurred after the HR change. If no Sync has run, trigger one manually from the Connector view. {% endstep %} {% step %} **Check the Field Mapping for the changed attribute** Go to **Connectors** → your Connector → **Field Mappings** and confirm that the attribute you expect to update is mapped from the HR source to the Entra ID target. If the field is not mapped, changes to it will not sync. {% endstep %} {% step %} **Check for an exclusion on the individual user** In the **Identities** view, search for the employee. If they are marked as excluded from Sync, their record will not update. Remove the exclusion if it was applied in error. {% endstep %} {% endstepper %} *** ## Login issues **Symptom: Cannot log in — "Access Denied"** You have not been granted an AOH Sync role. Ask your AOH Sync Administrator to add you under **Administration** → **Access Management**. See [Access Management](/administration/access-management). **Symptom: Cannot log in — MFA prompt loops or fails** AOH Sync uses your organization's Entra ID for authentication, including any MFA policies your organization has configured. If MFA is failing, contact your internal IT team to verify your MFA method is working. **Symptom: Logged out unexpectedly** Sessions expire based on your organization's Entra ID session policy. Log in again. If you are being logged out unusually frequently, your Administrator can adjust the session lifetime in Entra ID conditional access settings. *** ## Connector shows connection errors **Symptom:** The Connector status shows a connection failure or the last Sync log shows an authentication error against the Source System. {% stepper %} {% step %} **Test the connection** Go to **Connectors** → your Connector → **Settings** and use the connection test option. This confirms whether AOH Sync can reach your HR system with the current credentials. {% endstep %} {% step %} **Check whether credentials have expired** HR system API keys and passwords expire. Go to **Administration** → **Vault** and verify the secret used by this Connector is current. Update it if the credential has rotated. See [Vault](/administration/vault). {% endstep %} {% step %} **Check that the HR system is accessible** Confirm the HR system is reachable from your environment. If your HR system recently changed its API endpoint or security settings, update the Connector configuration to match. {% endstep %} {% endstepper %} *** ## Sync errors in the log **Symptom:** The Sync History shows completed with errors; individual records show error codes. | Error | What it means | What to do | | ------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Invalid email format | The email address in HR is malformed (missing @, extra spaces, or invalid characters) | Correct the email in your HR system and re-sync | | Manager not found | The manager reference on the record does not match any identity in Entra ID | Verify the manager's email in HR, sync the manager first if they are also new | | Duplicate record detected | Two HR records have the same identifying field (employee ID or email) | Resolve the duplicate in your HR system | | Required field missing | Email, first name, last name, or employee ID is blank | Add the missing data in HR and re-sync | | Rate limit — will retry | Microsoft's directory service has temporarily throttled requests | No action needed; AOH Sync retries automatically | | Connection failed | AOH Sync could not reach the HR system or Entra ID | See "Connector shows connection errors" above | If you see an error not listed here, copy the exact error text and email it to . *** ## Entra ID groups are not updating **Symptom:** Users are not being added to or removed from expected Entra ID groups after a Sync. {% stepper %} {% step %} **Confirm group Sync is enabled** Go to your Connector's **Settings** and verify that group Sync is active. {% endstep %} {% step %} **Review the group membership rules** Go to **Connectors** → your Connector → [**Field Mappings**](/feature-reference/connectors/field-mappings) and confirm the rule criteria match the user's current HR attributes. If the user's department or job title does not match the rule, they will not be added to the group. {% endstep %} {% step %} **Check for manual overrides in Entra ID** Group memberships managed by AOH Sync should not be edited manually in Entra ID — the next Sync will overwrite manual changes. If a manual change was made and reverted by AOH Sync, update the rule instead. {% endstep %} {% endstepper %} *** ## Users unexpectedly removed from Entra ID **Symptom:** User accounts were disabled or deleted in Entra ID after a Sync ran. {% hint style="warning" %} If accounts were removed and you need to restore them, deleted Entra ID accounts can often be recovered from the Entra ID recycle bin within 30 days. {% endhint %} AOH Sync deprovisions accounts when the corresponding HR record is marked as terminated or when the record falls outside the configured Sync scope. Check whether: * The employee was marked terminated in your HR system (intentionally or in error). * A scope change in the Connector excluded a group of users that previously synced. * Your HR system returned an unexpectedly small dataset (an API error may have appeared as mass terminations — AOH Sync has a deletion threshold that limits how many accounts it will remove in a single Sync, and it should have flagged this). Contact support if you believe accounts were removed incorrectly and you need help with recovery. *** ## Related * [FAQ](/help-and-support/faq) * [Contact Support](/help-and-support/contact) * [Connector Sync History](/feature-reference/connectors/logs) * [Audit & Status Logs](/administration/audit-and-status-logs) * [Vault](/administration/vault) # FAQ Answers to the questions AOH Sync administrators ask most often. *** ## General **What does AOH Sync do?** AOH Sync reads identity data from your HR system and writes it to Microsoft Entra ID (formerly Azure Active Directory). When a person is hired, changes roles, or leaves, AOH Sync ensures their Entra ID account and group memberships reflect the HR record automatically. **What HR systems does AOH Sync support?** AOH Sync connects to HR systems through a Connector. Supported connection methods include REST API and SFTP file export. Workday and BambooHR are common sources; any HR system that exposes employee data via API or structured file export can be integrated. Contact support at for a specific compatibility question. **What is the target identity system?** The current target is Microsoft Entra ID. AOH Sync writes directly to Entra ID using Microsoft's standard directory interfaces. It manages users, group memberships, and directory attributes. **Does AOH Sync replace Entra ID or Azure AD Connect?** No. AOH Sync is not an identity provider and does not replace Azure AD Connect. It automates the provisioning and deprovisioning of identities inside Entra ID based on what your HR system says. Your existing Entra ID policies, MFA settings, and conditional access rules remain in effect. *** ## Authentication & access **How do I log in to AOH Sync?** AOH Sync uses your organization's Entra ID for authentication — there are no separate AOH Sync credentials. Go to your AOH Sync URL and click **Sign in with Microsoft**. Complete any MFA prompt your organization requires. **I see "Access Denied" when I try to log in. What should I do?** This usually means one of three things: you have not been granted an AOH Sync role, you are signing in with a personal Microsoft account instead of your work account, or your session has expired. Ask your AOH Sync Administrator to check your access under **Administration** → **Access Management**. See [Access Management](/administration/access-management) for details on roles. **Why can I not see a particular feature?** AOH Sync uses role-based access control. The features visible to you depend on the role your Administrator has assigned. Roles are described in [Roles & Permissions](/core-concepts/roles-and-permissions). *** ## Sync behavior **How often does AOH Sync sync data?** Sync frequency is configured per Connector. Most organizations run an incremental Sync on a schedule (commonly every 15–60 minutes) and a full Sync nightly. You can also trigger a Sync manually at any time. See [Connector Schedule](/feature-reference/connectors/schedule) for configuration details. **What triggers a sync?** A Sync runs when the schedule fires or when you click **Run Now** in the Connector view. Schedules are configured in **Connectors** → your Connector → **Schedule**. **Why was a user skipped during sync?** AOH Sync skips a record when required fields are missing (email address, first name, last name, or employee ID), when the record matches an exclusion rule, or when no changes are detected since the last Sync. The Sync log in **Connectors** → your Connector → **Sync History** shows the reason for each skipped record. **Can I edit user data directly in AOH Sync?** No. AOH Sync treats your HR system as the source of truth. All changes to identity data must be made in the HR system; AOH Sync propagates them to Entra ID on the next Sync. **What data does AOH Sync read from my HR system?** AOH Sync reads identity-related attributes only: names, work email, employee ID, department, job title, manager reference, location, and employment dates. It does not access salary, compensation, personal addresses, or any other HR data outside identity attributes. The exact fields synced depend on your Connector's Field Mapping configuration. *** ## Groups & memberships **How are users assigned to Entra ID groups?** Group membership rules are defined in your Connector's [Field Mappings](/feature-reference/connectors/field-mappings) configuration. Rules match HR attributes (such as department or job title) to Entra ID groups. When an employee's attributes change, AOH Sync updates their group memberships on the next Sync. **A user is not in the right group. What should I check?** First confirm the employee's attributes in your HR system are correct. Then check whether the relevant group rule in AOH Sync matches those attributes. Most group discrepancies trace back to an HR record that does not yet match the rule criteria, or to a Sync that has not run since the HR change. **Can I manually add a user to a group that AOH Sync manages?** Manual changes to Entra ID groups managed by AOH Sync will be overwritten on the next Sync. If you need a user in a group for a reason not captured in HR, ask your Administrator to create a rule that covers the case, or exclude that group from AOH Sync management. *** ## Data & security **Where is my data stored?** AOH Sync is deployed as a single-tenant virtual machine in your own Azure subscription. Identity data flows through your instance and is written to Entra ID; it is not stored in any shared or third-party system. See [Where Your Data Lives](/trust-security-and-data-handling/data-residency) for full details. **Is data encrypted?** Yes. All data in transit uses TLS. Credentials and secrets are stored in AOH Sync's built-in [Vault](/administration/vault), which is part of your deployment and runs entirely within your Azure subscription. See [Encryption](/trust-security-and-data-handling/encryption). **What permissions does AOH Sync hold in Entra ID?** AOH Sync uses a Microsoft App Registration that you create and control. The permissions granted are documented in [Microsoft Entra Permissions Requested](/trust-security-and-data-handling/entra-permissions). **Who can see my data?** Access to AOH Sync is controlled entirely by your Administrator through role assignments. All actions are recorded in the Audit Log. See [Audit & Status Logs](/administration/audit-and-status-logs). *** ## Errors & failures **What happens when a sync fails?** Failed records are isolated — they do not block the rest of the Sync. Each failure is logged with a reason code. AOH Sync retries failed records on the next scheduled Sync. You can see failures on the Dashboard and drill into details in the Connector's Sync History. **What do common error messages mean?** See [Troubleshooting](/help-and-support/troubleshooting) for a list of common symptoms and how to resolve them. *** ## Related * [Troubleshooting](/help-and-support/troubleshooting) * [Contact Support](/help-and-support/contact) * [How AOH Sync Works](/core-concepts/how-aohsync-works) * [Roles & Permissions](/core-concepts/roles-and-permissions) # Contact Support How to reach the AOH Sync support team when you need help. ## Before you reach out Working through the documentation first often saves time. Check: * [Troubleshooting](/help-and-support/troubleshooting) — symptoms and step-by-step resolutions for the most common issues * [FAQ](/help-and-support/faq) — answers to frequent questions about sync behavior, access, and data If the issue is not covered there, the information below will get you to the right person quickly. ## Email support Send a message to **** for any issue that is not an active outage. To help us respond without back-and-forth, include: | What to include | Where to find it | | ------------------------------- | -------------------------------------------- | | Your organization name | Shown in the top navigation bar | | A description of the issue | What you were trying to do and what happened | | The exact error message or code | Copy the text or attach a screenshot | | When the issue started | Approximate date and time | | Steps you have already tried | Helps us skip suggestions you have ruled out | ## Documentation site The full AOH Sync documentation is available at ****. Use it to browse all feature guides, concepts, and administration topics. ## What to expect {% hint style="info" %} Support is staffed during business hours. For critical issues — complete sync failures or inability to log in — flag your email as urgent in the subject line so it routes to the on-call queue. {% endhint %} | Priority | Definition | First response target | | -------- | ------------------------------------- | ----------------------- | | Critical | Complete outage, no workaround | Within 1 business hour | | High | Major feature broken | Within 4 business hours | | Standard | Partial impairment, workaround exists | Within 1 business day | ## Related * [Troubleshooting](/help-and-support/troubleshooting) * [FAQ](/help-and-support/faq)