Use SDK Cmdlets to Add Properties to the Microsoft 365 User Profile Card

The Microsoft 365 profile card displays information about users. The information show in a profile card comes from the user’s Entra ID account. By default, Microsoft 365 limits the properties shown by the profile card to the set that they consider to be most important. Organizations can customize the Contact tab of the  profile card to reveal some of the properties that are not shown by default. However, not every property of an Entra ID user account is available for the profile card. Some, like the employee hire date, are not supported.

In 2020, I wrote about how to customize the profile card. At that time, the profile card API was in beta. The production Graph endpoint now supports the profile card API, and it’s also supported by cmdlets in the Microsoft Graph PowerShell SDK. I used version 2.9 of the SDK for this article.

The Microsoft documentation for customizing the profile card is a little outdated. At the time of writing, it uses V1.0 of the SDK and is based on the beta API. Because the API is now in production, it follows that the latest SDK cmdlets use that API. In any case, the instructions contained in the documentation are a reasonable guide.

Customized User Profile Card Available to All

The most important point about customizing the profile card is that any change is exposed to all users. You cannot customize the profile card for a subset of the user population such as a targeted administrative unit. This fact creates difficulties in multinational organizations where local privacy regulations might prevent the display of certain information held in user account properties.

As already mentioned, only certain user account properties are available for customization. Basically, you can add six standard properties:

• UserPrincipalName.
• Fax.
• StreetAddress.
• PostalCode.
• StateOrProvince.
• Alias.

Of course, including these properties in the profile card is useless unless information is populated in the directory for all user accounts. That often doesn’t happen.

The the fifteen custom attributes inherited from Exchange Server (different to the custom security attributes that can be defined for Entra ID) are also supported. Many organizations use these attributes to store information about users such as personnel numbers, cost centers, employee type, employee job codes, seniority level, and even the date of last promotion. Dynamic distribution lists and dynamic Microsoft 365 groups.

Add an Attribute to the Profile Card

To add one of the six standard or fifteen custom attributes to the profile card, construct a payload in a PowerShell hash table. The table contains the property name and its display name (annotation). Then run the New-MgAdminPeopleProfileCardProperty cmdlet passing the hash table as the body parameter (the same as passing a request body to a Graph request). This command adds CustomAttribute15 and tells Microsoft 365 that the user profile card should refer to the property as the “Employee Type.”

Connect-MgGraph -Scopes "PeopleSettings.ReadWrite.All","PeopleSettings.Read.All" -NoWelcome

$AddPropertyDetails = @{
  directoryPropertyName = "CustomAttribute15"
  annotations = @(
    @{ displayName = "Employee Type" }
  )
}

$AddPropertyDetails

Name                           Value
----                           -----
directoryPropertyName          CustomAttribute15
annotations                    {Employee Type}

New-MgAdminPeopleProfileCardProperty -BodyParameter $AddPropertyDetails

Id DirectoryPropertyName
-- ---------------------
   CustomAttribute15

It takes at least 24 hours before the profile card picks up customized properties. When they do, they appear on the Contact tab of the profile card. Figure 1 shows three custom properties for cost center, preferred drink (a historic part of the Active Directory schema), and employee type. If a custom properties doesn’t contain any information for a user, it won’t appear on the profile card.

To check the set of attributes added to the profile card with PowerShell, run the Get-MgAdminPeopleProfileCardProperty cmdlet. This output tells us that the profile card is configured to display three optional properties and three custom properties:

Get-MgAdminPeopleProfileCardProperty

Id DirectoryPropertyName
-- ---------------------
   userPrincipalName
   customAttribute12
   StreetAddress
   Postalcode
   CustomAttribute9
   CustomAttribute15

If you make a mistake, you can remove a property from the profile card by running the Remove-MgAdminPeopleProfileCardProperty cmdlet. For example, this command removes the Drink attribute (stored in CustomAttribute9) from the profile card:

Remove-MgAdminPeopleProfileCardProperty -ProfileCardPropertyId CustomAttribute9

Note that the profile card property id parameter is case sensitive. You must pass the property name as returned by the Get–MgAdminPeopleProfileCardProperty cmdlet.

Adding a Translated Label for a Custom Profile Card Property

The documentation makes a big thing about defining a language-specific value for a custom property. This is done using the Update-MgAdminPeopleProfileCardProperty cmdlet. This example shows how to add a French language label for CustomAtrribute15:

$LocalizationHash = @{}
$LocalizationHash.Add("languagetag","fr-FR")
$LocalizationHash.Add("displayName","Type d’employé")

$UpdatePropertyDetails = @{
   annotations = @(
    @{
    displayName = "Cost Center"
   localizations = @( $LocalizationHash )
     }
    )
}
Update-MgAdminPeopleProfileCardProperty -ProfileCardPropertyId 'customAttribute15' -BodyParameter $UpdatePropertyDetails

This command works, but it only works for a single language. If you want to have labels for multiple languages, you’ll be sadly disappointed because Update-MgAdminPeopleProfileCardProperty (and its Graph API counterpart) overwrite the language configuration each time.

You could argue that this is disappointing for multinational organizations that want to have fully-translated interfaces for all languages in use. Being restricted to a single language alternative is a strange approach to localization, especially for a company that does so much to deliver local language translations for user interfaces. The counterargument is that the properties chosen for display in the profile cards are likely to be well understood by anyone in an organization.

Work Still to Do

Not much has changed in customizing the profile card since 2020. The API is now production rather than beta and the Graph SDK supports the action, but that’s it. Coverage for multiple local language labels would be nice but that’s still elusive.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Expertise Noted in Viva Topics Now Appears on Microsoft 365 User Profile

I consider Viva Topics to be the most interesting part of the Microsoft Viva Suite. Viva Topics allows organizations to mine knowledge from documents stored in SharePoint Online to extract topics of interest to the organization. Knowledge managers then decide which topics to publish to appear in applications and who within the organization have expertise in the topics. The idea is to allow end users to find information more easily, including people that they should consult if they need additional information.

Since its introduction in 2021, Microsoft has gradually expanded the set of apps that highlight topics to include high-traffic apps like OWA and Teams chat. Teams channel conversations do not support Viva Topics, but the beta of the Teams 2.1 client does (Figure 1).

Showing Knowledge in People Cards

Published on 28 March 2023 in Microsoft 365 message center notification MC534310 (Microsoft 365 roadmap item 88697) and now rolling out, the Microsoft 365 user profile card now highlights details of the topics that someone has expertise in, but only if the viewing user has a Viva Topics or Viva Suite license (Figure 2).

This change is part of a process to increase the value of the profile card. The last enhancement was the addition of pronouns, another example is the inclusion of local time information, a feature that first appeared in Teams. The roadmap item specifies that the Viva Topics data appears in “profile cards displayed through Outlook” while MC534310 says that the information is available in profile cards for OWA and SharePoint web parts. Confusingly, MC534310 also mentions that you can see the information in “other Office apps.” My conclusion is that OWA is first to implement the feature and that it will gradually appear throughout Microsoft 365. Time will tell.

Navigating Viva Topics

Selecting a skill brings the user to the topic page (Figure 3). Here they can find additional information about the topic, such as its connections with other topics. You can also see the list of confirmed and suggested experts for the topic.

Skills and Expertise

Two sets of topics appear in the profile card. If you look at Figure 2, the first set (with a tick mark) contains published topics. The second set contains suggested topics that Viva Topics believes the person is knowledgeable in. However, a knowledge manager has not yet reviewed and published the topic and connected the person to it. In some ways, it’s like the verification process to receive a checkmark for Twitter.

Remember that Viva Topics derives its opinion about user expertise based on the contributions made in documents stored in SharePoint Online (all or some of the sites in a tenant can contribute). Depending on the age of the document or the review cycle for topics, the lists can reflect old product names, projects, and so on. For instance, because I write about many elements in Microsoft 365, Viva Topics considers that my account is connected to a large set of topics (Figure 3). Many of the suggestions are old and will never be confirmed. Others are candidates for updating because the name of a product has changed, and others are obsolete and should be removed. Maintaining the topics and skills is an important role for knowledge managers to ensure that users see relevant and valuable topics. Obviously, I have not been doing a good job as a knowledge manager.

Extends the Reach of Viva Topics

Including topicsin the user profile card seems like a good idea. If you have the necessary license, the organization has already taken the plunge to use Viva Topics to harness and refine knowledge, so it’s good to have the information available through as many places as possible. On the other hand, if you don’t use Viva Topics you won’t care. And that’s just fine too.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

People Insights from LinkedIn and Viva Insights Appear

Following up last week’s news about the ability to add pronouns to the user profile card, the change announced in message center notification MC521886 (1 March) to bring insights about people to profile cards displayed in Teams is rolling out. This is Microsoft 365 roadmap item 116006. Microsoft expects to finish the deployment worldwide by the end of March.

Teams has been able to display information about LinkedIn contacts in user profile cards for a year or so. What’s changing is that instead of the basic information about someone such as their current job, experience, skills, and education, you now see “insights” about a person such as a notice when their birthday arrives (Figure 1).

Reaching Out to Your Contact

As this is the Teams version of the profile card, it should come as no surprise that you can send a chat message to your contact to congratulate them about their advanced age. Alternatively, the Say happy birthday button is a drop-down menu with options to start a chat, have an audio or video call, or send email. The latter option launches the OWA compose message screen with an oddly uppercased recipient address (Figure 2). Given the widespread use of machine learning and artificial intelligence within Microsoft 365, you’d expect that Teams would compose the congratulatory message too! Alas, you’ll have to come up with some suitable text.

Once you respond to the prompt for your contact’s happy birthday, the insight disappears.

Other People Insights for the User Profile Card

Apart from birthdays, the insights you see include posts a contact makes to their LinkedIn account (shown in the LinkedIn tab), career changes, and pending meeting invitations. Microsoft emphasizes that the same insights are available in other Microsoft 365 apps, like OWA and Outlook.

I have never seen a birthday notification in Outlook for Windows, OWA, or the latest build of the Monarch client, but maybe I use the wrong versions. Microsoft’s documentation describes how Microsoft 365 generates people insights from LinkedIn and Viva Insights and how apps display the insights. Some delay occurs before Viva Insights generates information to show like “RSVP nudges” for outstanding invitations. The page shows OWA highlighting a contact’s birthday. Perhaps it’s a case where if you deal with an insight in one app, Microsoft 365 hides the insight for the other apps.

More Integration Everywhere

I’m beginning to think that Microsoft rewards engineers for finding ways to stitch different Microsoft 365 components together. Adding people insights to the user profile card is an example. Some of the information added recently, like someone’s local time zone, is very useful. I’m not sure about the latest batch.

Another example of stitching components together is the appearance of the Storyline post option in the new item menu for the latest OWA and Monarch clients (Figure 3). This action posts a text message to Viva Engage (aka Yammer) to appear on a user’s storyline.

I don’t think any great demand exists in the ranks of Outlook users to do such a thing but obviously the powers-that-be inside Microsoft consider this to be a very good thing. Hopefully, Microsoft’s famed telemetry will reveal the truth and persuade Microsoft to quietly drop the notion.

A common complaint I hear from Microsoft 365 administrators is that they wish Microsoft paid more attention to making the apps bulletproof instead of delivering new functionality that no one wants. But it’s important to keep engineers and product managers busy, and that’s why we see some of the changes that appear in message center notifications. I like some of the people insights I see, but know that other won’t. Beauty lies in the eye of the beholder.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Drink and the Active Directory Schema

Last week, Twitter was full of news about the drink attribute, which is part of the Active Directory schema and defined in Microsoft documentation as “The drink (Favorite Drink) attribute type specifies the favorite drink of an object (or person).” The Microsoft 365 profile card displays lots of information about people, but it doesn’t show their favorite beverage.

Quite why drink was ever added to Active Directory is a mystery, but it’s there for all versions of the Windows Server operating system from Windows Server 2003 and available for people to use as they wish. However, it’s not in Azure Active Directory, and again no one can explain why. But it’s not and, according to Microsoft, will not be.

Use Custom Attributes Instead for the Microsoft 365 Profile Card

The lack of drink in Azure AD poses a quandary to those who need to populate the attribute. You cannot extend the Azure AD schema to add attributes, so the only thing to do is to make the best of what’s available. In a nutshell, you can use one of the fifteen single-value custom predefined in Azure AD for organizations to use as they wish. You can’t rename the attributes, but you can use them to hold data.

A quick check of mailboxes revealed that CustomAttribute9 wasn’t in use. It’s important to check to make sure that the chosen attribute isn’t used to store information used for another purpose. With the decision made. To update CustomAttribute9 with a user’s drink preference, you can set the value for their mailbox with PowerShell using the Set-Mailbox cmdlet as follows:

Set-Mailbox -Identity James.Joyce -CustomAttribute9 "Beer"

Updating a custom attribute for an Exchange Online mailbox leads to synchronization of the information to the mailbox owner’s account in Azure AD. I spent some time looking at how to update the custom attribute using the Azure AD PowerShell module and could find no method to do this.

It would be nice to be allowed use one of the five multi-value custom attributes available for mailboxes and also in Azure AD (ExtensionCustomAttribute1 through ExtensionCustomAttribute5) as you could then store the preferred brand name along with the choice of beverage, but these attributes aren’t currently supported for customization of the profile card.

Update Azure AD Schema to Display Drink on the Microsoft 365 Profile Card

Once the chosen attribute is populated, we can use the Graph Explorer to update the Azure AD schema to make information about users’ preferred drinks appear in the profile card (also known as the people card). I used this payload to define that the contents of CustomAttribute9 is displayed as Drink in the Microsoft 365 profile card.

{
            "directoryPropertyName": "CustomAttribute9",
            "annotations": [
                {
                    "displayName": "Drink",
                    "localizations": [
                        {
                            "languageTag": "de",
                            "displayName": "Getränk"
                        }
                    ]
                }
            ]
        }

The customization to the profile card doesn’t happen quickly and it can take up to 24 hours before you see the effect. Eventually, all the necessary processes click into place and the profile card will display the information (Figure 1).

It’s unlikely that many organizations will decide that including drink in a customized profile card is an essential contribution to the business. But in the interest of completeness, we felt it important to let people coming from the on-premises world to the cloud that although the drink attribute doesn’t exist in Azure AD, they can still make it show up.

Sometimes we come across strange but interesting technical topics as we research and write the Office 365 for IT Pros eBook. This post falls into that category. On a serious note, it’s yet another example of using the Graph Explorer to do real work. But apart from that… it’s just an excuse to have a drink.

Making the Microsoft 365 Profile Card Your Own

Updated 12 November 2023

In Office 365 notification MC217813 (published 1 July and updated on 15 July), Microsoft announced that: “You will be able to customize profile cards according to your organization business needs. The profile card is sometimes referred to as a contact card or people card.” (Microsoft 365 roadmap item 61502).

The new functionality sounds promising. The profile or people card displays information about someone in different places in Microsoft 365 applications. For instance, you can select an email sender or recipient in Outlook or Outlook mobile to view the details of that person. If they’re someone in your organization, the profile card shows you information from their Azure Active Directory account. The information is more limited for external people.

Customizing the Profile Card

The announcement points to documentation about how to customize the profile card. Essentially, you update the ProfileCardProperty Graph resource to add new information to the Microsoft 365 profile card. Six standard Azure Active Directory properties can be added along with the fifteen custom attributes available for organizations to use as they wish (like CustomAttribute11, which Microsoft recently considered using to identify the room mailboxes needed for its Workspaces feature). Custom attributes are used for many purposes, including to hold organizational information (like cost centers and division names), mark mailboxes for special processing, and so on.

Nice as it is to be able to customize the profile card, the immediate barrier facing many tenant administrators is not knowing how to interact with the Graph to update the ProfileCardProperty resource. Not everyone has mastered Graph programming, and administrators who know PowerShell might not yet have ventured into interacting with the Graph (some examples of using PowerShell with the Graph are listed below).

Graph Explorer Delivers an Answer

As it turns out, the Graph Explorer makes it easy to apply the necessary changes. This is a browser interface to allow people to interact with the Graph and get to know how Graph transactions work against different endpoints, such as Groups, Outlook, Planner, and SharePoint. You can run commands against test data or, after signing into a tenant account, against live data. Programmers can grab code snippets generated for transactions by the Explorer in C#, Java, JavaScript, and Objective-C and include the code in their programs. All in all, the Graph Explorer is a very useful tool.

Using Graph Explorer to Update the Profile Card

The key points about using the Graph Explorer to update the ProfileCardProperty resource are:

• Sign in with an administrative account for the tenant.
• Use a POST command to update the https://graph.microsoft.com/v1.0/admin/people/profileCardProperties endpoint.
• Put the update you want to execute in the request body. For example, to add the PostalCode property to the profile card, I put {“directoryPropertyName”:”Postalcode”} in the request body.
• Click Run query when you’re ready. If everything’s been done right, you should see a 200 response. This means that the Graph has accepted the update.

Figure 1 shows the Graph Explorer after running a successful update. You can see the 200 response.

You can make multiple updates to add more properties or add all the properties at one time by including them in the request body. For example, this request body specifies three properties to add to the profile card:

{
  "directoryPropertyName": "StreetAddress",
  "directoryPropertyName": "PostalCode",
  "directoryPropertyName": "userPrincipalName"
}

Microsoft warns that it takes up to 24 hours for the changes to show on user profile cards. It also seems that you need to add updates one by one and wait until an update is active before applying another. To check the current state of the ProfileCardProperty resource, you can run a GET command to see what’s returned by https://graph.microsoft.com/v1.0/admin/people/profileCardProperties.

Figure 2 shows that I have added two of the standard properties (UserPrincipalName and StreetAddress) and CustomAttribute12. Note that the custom attribute is assigned a display name of “Cost Center” to make its use more obvious to end users.

The Microsoft Graph PowerShell SDK can retrieve details of custom properties. For example, this output shows that the tenant customized the profile to include three standard attributes for Azure AD accounts (userPrincipalName, StreetAddress, and PostalCode) and added two custom attributes to display the user’s cost center and preferred drink, which are stored in CustomAttribute12 and CustomAttribute9 respectively:

Connect-MgGraph -NoWelcome -Scopes "PeopleSettings.ReadWrite.All","PeopleSettings.Read.All"

Get-MgAdminPeopleProfileCardProperty | Format-List

Annotations           : {}
DirectoryPropertyName : userPrincipalName
Id                    :
AdditionalProperties  : {}

Annotations           : {Cost center}
DirectoryPropertyName : customAttribute12
Id                    :
AdditionalProperties  : {}

Annotations           : {}
DirectoryPropertyName : StreetAddress
Id                    :
AdditionalProperties  : {}

Annotations           : {}
DirectoryPropertyName : Postalcode
Id                    :
AdditionalProperties  : {}

Annotations           : {Drink}
DirectoryPropertyName : CustomAttribute9
Id                    :
AdditionalProperties  : {}

Viewing Custom Profile Cards in Applications

After the Graph processes everything and applications refresh their cache, you’ll see the customizations show up in the profile cards displayed by applications. Figure 3 shows how OWA displays customized contact information in the Microsoft 365 profile card while Figure 4 shows how the card appears in Outlook Mobile.

The customized attributes don’t appear for guest accounts.

If you make a mistake and add the wrong attribute or want to start over, you can remove an attribute from the organization settings by running a DELETE request. For example, to remove CustomAttribute15 from the set shown on the user profile card, run a DELETE request against https://graph.microsoft.com/v1.0/admin/people/profileCardProperties/customAttribute15

Gets Real Work Done

The notion of having to write code to interact with the Graph might well have turned people away from even considering customizing the profile card. The Graph Explorer allows you to do the job without writing a single line of code. It’s a great example of using an available tool to achieve a goal in a way that the authors of the feature probably never considered.

Some PowerShell with Graph Articles

How to report SharePoint Online site usage.

Fetching Azure AD Account Sign-in Information.

Fetching Planner Data for a Single User.

Generating a User Activity Report.

Handling pagination when fetching Graph data.