Distinguish the identities in the problem
Enterprise systems contain several kinds of identity: a person signing in, an organisation buying a service, a physical asset and a transaction recorded by a source. These identities have different lifecycles and authorities. A shared email address may help locate a user account but does not necessarily establish the legal identity of a customer or the ownership of a contract.
Name the entity type and the decision that depends on identifying it. Decide whether the intended object is a legal entity, a business account, a site or a corporate group. Many apparent matching problems are actually differences in entity grain. Resolve that distinction before selecting algorithms, because no similarity threshold can make two different business concepts identical.
Preserve source namespaces and stable keys
A local identifier is meaningful within the system and scope that issued it. Two source systems can both contain customer 1042 without referring to the same customer. Represent a source identity with its namespace and local key, and preserve it even if an enterprise identifier is introduced. This allows a reviewer to trace a mapping back to the original record.
Avoid using a mutable display name as the durable key. Names, email addresses and equipment labels can change or be reused. Document the issuer’s guarantees about stability and uniqueness, including whether a deleted identifier can return. RDF’s use of IRIs illustrates the importance of globally distinguishable resource identifiers, while the enterprise still has to govern what each identifier denotes.
Make matching evidence explicit
Use authoritative references where available, such as a governed legal entity identifier or a source maintained cross reference. Record the basis for each mapping. When matching relies on attributes such as name, address or registration details, preserve the evidence and confidence separately from the final identity decision. Different use cases may require different review thresholds.
Provide outcomes beyond match or no match. An unresolved candidate, a probable association and a confirmed equivalence carry different operational implications. Route ambiguous cases to a responsible steward when the decision warrants it. Do not silently promote a probabilistic relationship into an authoritative join simply because a downstream workflow expects every record to have exactly one enterprise identity.
Plan for merges, splits and corrections
Organisations merge, assets are replaced and previously combined customer records are sometimes discovered to represent different entities. A mapping service must handle these changes without losing historical meaning. Record effective periods and the reason for each change. Distinguish a real business merger from a correction to a mistaken match, since they imply different interpretations of prior data.
Determine how downstream consumers learn about a correction and whether derived results need to be recomputed. Keep aliases or redirects where appropriate, but avoid making an old identifier point to a different entity without explanation. Test historical queries and cached results after a split. Identity maintenance is an operational workflow with consequences for reporting, permissions and customer communication.
Apply the correct standards to user identity
OpenID Connect defines an identity layer for authentication, including a subject identifier interpreted with its issuer. SCIM defines standard schemas for managing identity resources such as users and groups across systems. These address related but distinct concerns: establishing an authenticated identity and managing account representations. Neither automatically resolves the organisation’s business entities or grants access to every record associated with a user.
Keep authentication identifiers separate from application profile fields and business relationships. A change to an email address should not unexpectedly create a new principal or transfer another person’s access. Define deprovisioning and group update behavior, and review how identity changes affect existing sessions or cached permissions. Identity propagation must preserve the security meaning of the source, not just copy attributes.
Measure unresolved identity as a data condition
Track duplicate candidates, unresolved mappings, stale references and corrections that affect downstream products. Break these indicators down by source and entity type so the owner can act on them. A single percentage of matched records can hide a small group of critical contracts or assets whose identity remains uncertain.
Review difficult cases with domain stewards: reused names, shared addresses, corporate subsidiaries and replaced equipment. Preserve a correction path that does not require deleting the original evidence. Record unresolved assumptions and decide which uses require a confirmed identity before work can proceed.