> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/identity/unique-identifier.md). # Choosing the enterprise unique identifier Decide what the enterprise identifier actually is — a payroll employee number, a synthetic identifier you mint, or a composite — why large organizations invent their own, and why identifiers need not ## What this is, and when you need it [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) settles that the key must be a trusted, immutable workforce identifier. This page settles **what that identifier is** — whether you adopt one the organization already issues, invent one, or construct one from parts — and where it lives in OpenIAM. You need this page when the honest answer to "what is the one value that identifies a person across the whole estate?" is "it depends which system you ask". That is the normal answer in an organization with several payroll systems, a recent acquisition, or a large contractor population, and it is the reason large organizations so often end up minting an identifier of their own. ## The decision | Option | What it costs | What it buys | | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Adopt the HR employee number** | Only works if one HR system covers everyone, numbers are never reused, and non-employees have one | No new system of record, a value people recognise, and immediate availability in the joiner feed | | **Mint a synthetic enterprise identifier** | You now issue and hold an identifier: a minting mechanism, a rule for when one is issued, and a place it is written back to | One value per person across every subsidiary, every HR system and every population, including people payroll has never heard of | | **Composite: source system plus that system's local identifier** | A custom matching rule, and a crosswalk you own and must keep correct | Works without changing any source system, and is honest about the fact that no single value spans the estate | | **Adopt an external identifier** — a national identity number, a professional registration | Data-protection exposure, and populations that do not have one | Genuinely externally verified. Rarely worth the exposure, and unlawful to use this way in some jurisdictions | ## Why large organizations invent their own The pattern is consistent enough to plan for. An organization reaches for a synthetic identifier when at least one of the following is true, and in a hundred-thousand-person estate at least one always is: **There is more than one payroll.** A parent and its subsidiaries each run their own HR system, each issuing numbers in its own range. Two people in two subsidiaries hold employee number `10432`. Nothing upstream is going to fix that. **Numbers are reused.** Some payroll systems reissue a leaver's number after a retention period. A key that can be reissued is not a key — it is a slot. **A large population has no number at all.** Contractors, agency staff, partners, service accounts and machine identities are not on payroll. If the enterprise identifier is the payroll number, none of them can have one, and the population that most needs governance is the one the identity model cannot represent. **A person legitimately appears twice.** Someone who works for two subsidiaries, or who leaves and returns, has two payroll records and one identity. The identifier has to belong to the person, not to the employment relationship. **An acquisition is coming, or has just happened.** The moment two estates have to produce one view of a person, an identifier that belongs to one of them is not an enterprise identifier. The counter-argument is real and should be conceded: minting an identifier means the organization now operates an identity register, with the governance, the retention and the reconciliation that implies. That is a genuine cost. It is smaller than the cost of the failure modes it prevents, and unlike those, it is a cost you plan for. ## Where the identifier lives in OpenIAM Two placements, and the choice matters because it determines what a feed matches on: **The employee identifier field on the user.** A single string field, indexed for lookup. Matching on it is the best-behaved path in the product, and it is what a workforce feed should normally use. Its limitations are worth knowing: it is one field, so it holds one value, and it carries no uniqueness constraint of any kind. **A named user attribute.** Matching can compare a named attribute against its value set instead. Use this when the enterprise identifier is not the same thing as the payroll number and both need to be retained — the payroll number in the employee identifier field for people who have one, the enterprise identifier in an attribute for everybody. Name the attribute in the design and do not let it drift. What you should not do is overload one field with two kinds of value depending on population — employee number for staff, something else for contractors, in the same field. It matches until the day the two namespaces collide, and then it matches the wrong person. ### Minting one OpenIAM can issue the numbers. A **sequence generator** is a named integer that OpenIAM increments atomically across every node in the cluster, called from a synchronization or provisioning script — so two feeds running at once cannot be issued the same number. The name is the key, limited to 32 characters. One property of that mechanism belongs in the design rather than in the runbook: **deleting a generator restarts the series at 1**, and every number already issued becomes reissuable. If the enterprise identifier is minted this way, the generator is part of the system of record and belongs in the same change control and the same backup conversation as the database. Two design choices are worth settling at the same time: **Format.** Resist embedding meaning. A prefix that encodes the subsidiary, the year or the worker type is a value that has to change when the person does, which makes it mutable, which disqualifies it. A check digit, on the other hand, is cheap and catches transcription errors in every downstream system that will inevitably retype it. **Write-back.** An identifier that exists only in OpenIAM is an identifier the HR system cannot put on its next extract, which means every subsequent run has to match on something else to find the person it already minted one for. Decide early whether the identifier is written back to the source, held in OpenIAM and matched through a stable secondary value, or issued by a register upstream of both. ## Identifiers do not need to match across estates This is the point that usually resolves the "but the other organization uses a different identifier" objection, and it is worth stating early because it removes a whole category of imagined work. **Federation protocols carry identity translation.** OpenIAM as an identity provider decides what value goes into the assertion, with a resolver script available where the standard mapping cannot produce it. OpenIAM as a service provider resolves an incoming assertion against the principals of a nominated managed system, again with a resolver script as the escape hatch. Each side asserts and consumes the value that is meaningful to it. So two organizations federating do **not** need a shared identifier scheme. What they need is a deterministic, governed mapping at the bridge, and a stable identifier on each side of it. Insisting that both estates adopt the same identifier is a much larger programme than translating between two, and it is usually proposed by someone who has not been told translation is available. The same argument applies internally. A subsidiary that will not renumber its workforce does not have to; its numbers become the local identifier, and the enterprise identifier is the value that spans them. ## What we recommend **If one HR system covers every worker type, numbers are never reused, and non-employees are also registered in it — adopt the employee number.** Do not invent an identifier to solve a problem you do not have. **Otherwise, mint a synthetic enterprise identifier**, issue it to every person the organization has a relationship with regardless of population, and make it the correlation key. This is the right answer for most estates of this size, and the reason to make it early is that retro-fitting one means re-matching every account. **Keep it meaningless, keep it immutable, and issue it once per person.** Not once per employment, not once per subsidiary, not once per contract. **Do not require federated partners to adopt it.** Translate at the bridge. **Treat the minting mechanism as part of the system of record.** Whatever issues the numbers — a sequence generator here, or a register upstream — is now something that must be backed up, change controlled and never reset. The circumstance that changes this advice is a small, single-payroll organization with no acquisition history and no material contractor population. There, minting an identifier is overhead with no return. ## What OpenIAM does not do here * **No uniqueness is enforced on the employee identifier**, and none on a user attribute used as a key. The product will hold duplicates and match the first one it finds. * **There is no identifier registry object.** OpenIAM does not model "this person's identifiers in every system"; it models one employee identifier field and whatever attributes you define. * **There is no crosswalk between two organizations' identifiers.** Translation happens in resolver scripts and in the correlation configuration, and the mapping is data you own. * **Deleting a sequence generator restarts it at 1.** There is no protection against reissuing numbers that are already in use. * **A sequence generator issues integers, not formatted identifiers.** Any prefix, padding or check digit is produced by the script that calls it. * **Nothing writes the identifier back to the source for you.** Write-back is a provisioning integration to the HR system like any other, and needs a connector and an owner. ## Related * [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) — the decision this one implements. * [Designing for every population](/solution-architecture/identity/populations.md) — the populations that also need an identifier, and usually have no payroll number. * *Define a sequence generator* in the Administration Guide — the cluster-wide counter that mints one, and its limits. * Part 5, *Cross-organization federation* — where identity translation across estates is designed. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # 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.openiam.com/solution-architecture/identity/unique-identifier.md?ask=&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.