> 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/core-concepts/identities-accounts-users.md).

# 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.md) 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.md)
* [How AOH Sync Works](/core-concepts/how-aohsync-works.md)
* [Machine Identities](/core-concepts/machine-identities.md)
* [Browsing Identities](/feature-reference/browsing-identities/identities.md)
* [Field Mappings](/feature-reference/connectors/field-mappings.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/core-concepts/identities-accounts-users.md?ask=<question>&goal=<endgoal>
```

`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.
