In the Microsoft 365 platform, productivity and recommendations are created to inform users about their relevant data. For example, Microsoft Delve is an app showing such information to a user. Another service is Microsoft Viva Insights (formerly MyAnalytics) that sends out statistics according to the motto "Work smarter with personal productivity insights in Microsoft 365". While this can be very useful for users to quickly find and discover relevant data, works councils are often sensitive to personal data in a company. So how can we explain what is happening here and invalidate what data is visible to individual users and what data is visible to other users? Well, here is some information about the Microsoft 365 "works with" features.
When signals are collected
User actions and document interactions, so-called signals, are collected in the Microsoft Graph. This is the central place for storing and linking activities. The goal is to "improve productivity and wellbeing with data-driven, privacy-protected insights and recommendations for every user". Many actions are logged in order to create a relationship with other objects. For example, when you write an email to another user inside or outside the organization, the Graph creates a relationship with that user based on the intensity of emails you send to that user. When you create or open a document, this also establishes a relationship with that document (and co-authors). When you chat or call other users in Teams, linked activities are created and so on.
This also happens for user logins in the Security Graph and other actions to grant access. Various mechanisms check whether the login is allowed or whether there are security problems. To make it short, the Microsoft 365 system (Azure AD and all the security features) ensures that only authenticated users have access. These facilities ensure that the data is secure and that company guidelines (such as Conditional Access, MFA and many more) are followed.
Benefit from using relevant (and shared) data
The platform gathers information about activity to provide for safety, auditing, and user productivity. While the security functions are essential, user productivity means that every user receives automated assistance in finding their relevant data and in collaborating with other people. This is where the information of the Graph comes into play in order to consume this data quickly and easily - with (custom) apps, Delve, Viva Insights and more. The following screenshot from the Delve app delivers the relevant people and documents based on a user’s communication and collaboration patterns and business relationships with other users.
This view is user centric and only shows people the user is communicating with. Furthermore, only documents for which the user has access are displayed. In this example, Adele can open the documents and email attachments she's been working on in the past few days with one click. Also, she gets information about her coworkers, if she has access to shared documents, otherwise she sees no information. Here, her manager Megan has not shared any documents with Adele. Therefor, she has no access to Megan´s documents when Adele opens her relation with Megan as the following screenshot shows.
Rules for seeing data
These rules are always followed:
- Only you can see your private documents.
- Other people can't see your private activities, such as what documents you've read, what emails you've sent and received, or what Teams conversations you've been in.
- Other people can see that you've modified a document, but only if they have access to the same document.
- If you want to keep a document private, store it in OneDrive for Business and do not to share it with others.
- To prevent others from seeing a shared document, change the permissions so only you have access to the document.
See more at Are my documents safe in Delve?
Dig deeper
We wanted to dig a little deeper into the topic of determining what data is shown and about the relevance. So, we checked some organizational relationships with the underlying graph. This is what we tested and what we found out.
To test queries against the Microsoft Graph REST API, you can use tools like Microsoft´s Graph Explorer, Postman, PowerShell, curl, and of course, any other programming language. For a quick test, open the Graph Explorer in a browser, log in with your work account and try out the queries. The article Use the People API in Microsoft Graph to get information about the people most relevant to you informs about getting that "relevant people I am working with".
Test with common Graph queries
Some popular queries to get organizational data from the Graph are…
GET my profile: https://graph.microsoft.com/v1.0/meGET my photo: https://graph.microsoft.com/v1.0/me/photo/$value
GET my manager: https://graph.microsoft.com/v1.0/me/manager
GET my team memberships: https://graph.microsoft.com/v1.0/me/joinedTeams
GET users in my organization: https://graph.microsoft.com/v1.0/users
GET groups in my organization: https://graph.microsoft.com/v1.0/groups
GET group conversations: https://graph.microsoft.com/v1.0/groups/<id>/conversations
etc.
To learn more about Microsoft Graph, see the full documentation at Microsoft Graph REST API v1.0 reference. Find the hottest and latest Graph features at What's new in Microsoft Graph and in the Microsoft Graph Changelog.
You can also share your ideas and vote for new Graph features on the Microsoft 365 Developer Platform.
people - See who is relevant to you
With that toolset, we continue to investigate the relevance. We have collected some tests in a real world tenant to find out, how the relevance is collected and shown in the Graph. We used Graph Explorer to run the following query to get the desired data in the name of a user:
https://graph.microsoft.com/v1.0/me/people?$select=displayName,scoredEmailAddresses,personType
This returns the top 10 relations for the signed-in user Martina. This is the relevant part of the JSON result:
{
"id": "[someid]",
"displayName": "Christoph",
"scoredEmailAddresses": [
{
"address": "christoph@contoso.com",
"relevanceScore": 1554,
"selectionLikelihood": "notSpecified"
}
],
"personType": {
"class": "Person",
"subclass": "OrganizationUser"
}
}, …By default, the people in the response are sorted by their relevance to your query. We see the scoredEmailAddresses data and the personType data for the relationship of the signed-in user to Christoph.
The numeric value in the relevanceScore property is never an absolute value. It always represents a calculated number compared to the other values. We did not find any information about the selectionLikelihood property. In our tenant, it always showed "notSpecified", so we ignored it. Eventually there´s some information about this probability (how accurate the relevanceScore is?) somewhere in the Graph documentation or in the changelog, eventually we will check that later.
The personType shows the object type in Azure AD of the contact. We saw the following values:
- personType Person, subclass OrganizationUser - a user in the same M365 tenant
- personType Person, subclass PersonalContact - an external user
- personType Person, subclass ImplicitContact - an external user (but we are not sure what´s the difference to PersonalContact)
- personType Group, subclass UnifiedGroup - a M365 Group (we guess, other group types are shown here as well, as DistributionGroup)
In our sample, we put the top 5 results of one day in an Excel sheet to compare them.
It's also worth noting the fact that by default, Graph only reports mailbox results. So, this statistics is fully email-centric and NOT including Teams calls and chats. It is expected that this will change in the near future so that Teams calls and chats will be included (more than today).
How the relevanceScore is being determined
Delve and Viva Insights use the Graph to show a user the most relevant information. This information is represented by the relevanceScore property which stores a value representing the calculated importance of a relationship derived from the signals. For example, the relevanceScore from user A to user B is 500 and from user A to user C is 300, and so on. The apps don't show this value, but use it to sort relevance in their representation. To mention, custom apps can also use Graph to read that information with an app with People.Read or People.Read.All permissions.
Unfortunately, there is no official documentation existing, how the signals are collected and how the relevance is determined. It´s a black box that delivers ready-to-use information. However, we collected some insights about the relevance in the summary below. Note this data is always a snapshot.
Only mailbox relevant
As a side note, the documentation Types of results included informs that "By default, Microsoft Graph serves mailbox-only results, which are your saved contacts or people you are most likely to interact with. To retrieve organization-wide directory results, specify an HTTP header." The sample shows that the Graph search can be affected by an additional header:
"X-PeopleQuery-QuerySources: Mailbox,Directory"
Well, in our tests with that header (and in our tenant), this did not work at all. We got results only for "Mailbox" data. When running with "Directory" only, the result returned was always empty. No other keywords were accepted either, not even in the Beta Graph. So this ultimately depends on the tenant, or it is a future feature? Anyway, if you want to test yourself, check out the following links as well: Advanced query capabilities on Azure AD directory objects, Users API Advanced Queries, How to send custom headers to graph api when using person component and see the script at Powershell-Scripts/Graph101/PeopleModule.ps1.
To make it short, we expect Microsoft to change the influence of other services like Teams in calculating relevance in the near future as it would make sense.
See the difference, what others see about you
What happens, when an Administrator (or an app) accesses the relevance data? Well, we test with an Administrator and ask for the people data for a specific user, here for user Martina:
https://graph.microsoft.com/v1.0/users/<id>/people?$select=displayName,scoredEmailAddresses,personType
We see different data (but for the delivered data the same scores). Only users in our organization (OrganizationUser) are shown and we see the gap in the relevanceScore. The persons between Christoph and Doris (who was not shown before in the top 5 results) are missing, and the relevanceScore continues with 232 and below.
personTypes of subsclass PersonalContact and ImplicitContact are not shown for other users, while they are displayed to the user him/herself. This also corresponds to the security concept of the Graph.
"Works with" summary
Long story short, here is our summary based on the tests to learn more about the relevant personal data collected by various Microsoft 365 signals and displayed in Microsoft Graph.
- Microsoft Graph enables access to useful data about people and documents they interact with (see Use the Microsoft Graph API to integrate people intelligence in an app).
- Relevance is determined by the user’s communication and collaboration patterns and business relationships.
- Sorted by relevance: "relevanceScore": 300. A higher relevance score value corresponds to a more relevant result.
- The relevanceScore changes on a daily basis (it´s a snapshot).
- Graph Permissions: Requests require the People.Read (Delegated permission with user consent) or People.Read.All (Admin Consent) permission.
- Administrators can use the profile card API to customize how information about their organization surfaces within Microsoft 365 people experiences.
- Determining relevance is a black box and you are not allowed to see in the box.
- By default, Microsoft Graph (currently) serves mailbox-only results, which are your saved contacts or people you are most likely to interact with. Search results by specifying a different HTTP header did not work.
- Administrators see other results (Organizational persons) than the user himself/herself.
We hope this article helps you better understand the (current) relevance rating in Microsoft Graph.