> For the complete documentation index, see [llms.txt](https://docs.aohwv.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aohwv.dev/trust-security-and-data-handling/what-data-we-store.md). # 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.md) 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.md) 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.md) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency.md) * [Encryption](/trust-security-and-data-handling/encryption.md) * [Data Retention & Deletion](/trust-security-and-data-handling/retention-and-deletion.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.aohwv.dev/trust-security-and-data-handling/what-data-we-store.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.