What account identifiers should I include in a provider request?¶
Include every reliable identifier that helps the provider locate the correct cloud account or tenant.
The dangerous assumption is that an email address or display name is always enough.
What this means in practice¶
Accounts can be renamed, aliases can change and the same visible name can exist in several organisations.
For guest or federated access, include both the home identity and the guest identity where available.
If a file or resource is central, include its resource ID, file ID, folder ID or version ID.
Avoid including unrelated personal data merely in case it helps.
If the account has been renamed or transferred, include the relevant historical names and dates. This helps the provider search records created before the current display information existed.
What this may show¶
Useful identifiers may include the provider account ID, tenant ID, user-object ID, email address, username, domain, phone number, subscription ID and known aliases.
For a specific event, include event, session, request or correlation identifiers.
Where an identifier is obtained from a screenshot or user interface, record that source. Some displayed values are labels rather than the provider’s stable internal identifier.
What this does not show on its own¶
Do not guess identifiers or silently correct formatting. Preserve the original values and explain where each came from.
Where only a display name is known, provide the supporting date range, organisation and other contextual information, but recognise that the provider may not be able to identify the account confidently.
What to do next¶
Record the exact service and product because one provider may operate several independent account systems.
Key takeaway
Use stable provider identifiers, tenant context and known aliases to locate the correct account, and do not rely on a changeable display name alone.