What identifiers might a cloud account use?¶
One cloud account can have a display name, sign-in name, email aliases, an internal user ID, a tenant ID and separate recovery identifiers. They answer different questions. The visible name helps a person recognise the account; the provider's internal IDs help systems distinguish and join it reliably.
Dave changes his name without becoming a new user¶
Northstar originally gives Dave the Google Workspace address dave.harris@northstar.example. It later changes his primary address to dave.hughes@northstar.example. Google documents that the old address becomes an alias and the user's existing email, files and data remain available.
In Microsoft Entra, Dave's work identity might simultaneously have a display name, a user principal name and an opaque Graph id. The first two can be useful human labels. The object ID is the safer directory key for distinguishing that user from another Dave or following the same object through a rename.
The values are fictional. Preserve what each identifier is called, where it came from and when it applied; do not flatten them into one “username” field.
Build a schedule, not a bag of names¶
An identifier schedule makes changes and overlaps visible:
| Provider | Identifier type | Exact value | Relevant period | Source |
|---|---|---|---|---|
| Google Workspace | Primary email | dave.harris@northstar.example | Until 14 May | Original directory export |
| Google Workspace | Primary email | dave.hughes@northstar.example | From 14 May | Rename/admin record |
| Google Workspace | Alias | dave.harris@northstar.example | From 14 May | Current profile and change record |
| Microsoft Entra | Tenant ID | 7c31…e902 | Whole relevant period | Organisation/provider record |
| Microsoft Entra | User object ID | 4a86…91bd | Whole relevant period | Graph/directory export |
| Microsoft Entra | User principal name | dave@northstar.example | Confirm dates | Directory export and change history |
Use the provider's full values in working records. The shortened values above are only for the illustration. Preserve capitalisation, punctuation, field names and the source that supplied each value.
Use the identifier that fits the question¶
- Finding the correct customer environment: use the tenant, organisation or workspace identifier.
- Following one user object through a rename: prefer the stable provider object ID and retain the old and new visible names.
- Connecting an email or sharing event: preserve the exact address and whether it was primary, alias, guest or recipient value.
- Connecting a device or cloud session: use the user ID alongside the provider's device, session, request or correlation identifiers; do not substitute one for another.
- Suggesting a relationship between accounts: treat a recovery address, telephone number, payment reference or verified domain as a link to test, not proof of the human user.
The tenant or workspace is particularly important. The same-looking user label can occur in separate environments, and an external guest can have one identity in a home organisation plus a guest object in another.
Why a Google Workspace rename can affect searching
Google says an administrator can change a Workspace user's primary address without losing the user's existing data; the former address becomes an alias. Its Admin and Drive log documentation also warns that searching for a renamed user's events under the old name does not return the renamed user's events.
Preserve original exports and search both the relevant identity history and time range. A failed search for the old visible address is not proof that the continuing user object had no activity.
What Microsoft Graph calls the identifiers
Microsoft Graph describes an Entra user's id as a unique, read-only opaque identifier. It describes userPrincipalName as the Internet-style sign-in name and lists separate properties for mail, proxyAddresses, other mail addresses and synchronised on-premises identifiers.
That vocabulary helps prevent a common mistake: calling every address-looking value “the email” and assuming it has the same purpose or stability.
State precisely what the match establishes¶
Prefer:
The two Entra records refer to user object
4a86…91bdin tenant7c31…e902, although the displayed sign-in name changed during the period.
Avoid:
Both say Dave Harris, so they must be the same account.
The first statement exposes the keys and boundary used for the join. Another reviewer can test it.
The point to remember
Record identifiers by type, provider, tenant, date and source. Use stable internal IDs to join records, visible names to explain them, and recovery or contact details as connections that still require corroboration.
