> 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.aohwv.dev/trust-security-and-data-handling/what-data-we-store.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.