Thank you for making detailed document.
I understand item id is the unique identifier of the Office.context.mailbox.item, but I'm not sure about the range of unique from this document. Is this id unique all over the cloud service (Office 365 and Outlook.com) and all existing on-premises Exchange Servers? Or is the id unique only in cloud service (O365 and Outlook.com)?
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Thanks for the question @NT-D.
@exextoc, could provide an answer?
Assigning @ElizabethSamuel-MSFT to follow up on any necessary documentation changes.
@NT-D is there a specific scenario you are referring to?
This issue has been automatically marked as stale because it is marked as needing author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your interest in Office Add-ins!
This issue has been closed due to inactivity. Please comment if you still need assistance and we'll re-open the issue.
@exextoc Sorry for my late reply. Let me describe scenario.
In our app backend, we need unique id for db record, and need to have relation with each event in Office 365. Because our end-users exists across tenants, I want to know the uniqueness.
FYI: This document written by Identity team is useful example. It describe oid is GUID and range of uniqueness well.
https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens
|Claim | Format | Description|
|-- | -- | --|
oid | String, a GUID | The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they're considered different accounts, even though the user logs into each account with the same credentials. The oid claim is a GUID and cannot be reused.
The item id returned by the API is the EWS item id of the item. This is the primary documentation for the EWS item id: https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/ews-identifiers-in-exchange
Global uniqueness of the id isn't guaranteed. The documentation says only this about how the ID is constructed:
- Identifiers in Exchange are opaque. For example, the EwsId is created from several pieces of information that are not important to you as the developer, but are important to Exchange.
Since it's not guaranteed to be globally unique, it's not safe to use as the only identifier within a database used by multiple organizations.
Since you are storing the id, please be aware that the item id changes when the item is moved between folders:
- Don't assume that your ID will always be valid if you need to retrieve the item at a later time. If an item is moved in the store, the ID can change because of the way a move is handled. An item is actually copied, and a new ID is generated, and then the original item is deleted.
Also, please be aware if your add-in supports shared folder scenarios now or in the future, items shared with multiple users may also share an identifier (because multiple users have access to the same item). Then, it depends on your application whether you want multiple users accessing the same item to share information in your database as well.
Thank you @exextoc for sharing information. I understand there is no guaranteed and got new insights from your advice.
Let me share 2 feedbacks
Glad to help, and thanks for the feedback.
@ElizabethSamuel-MSFT for feedback on adding a link to EWS Identifiers from the itemId documentation.
If you do need an immutable ID, this REST API can exchange a REST id for an immutable id. (The EWS id can be converted locally to the REST id format).
You can add a request for an immutable id API here on our user-voice page (I didn't find an existing request for it there). Feature requests on user-voice are considered when we go through our planning process.
@NT-D I'll go ahead and close this now. Your recommended doc updated should be published soon.
Thanks.