Table of Contents
The Odd Case of Invisible Skills
Last week, I wrote about how to use Microsoft Graph PowerShell SDK cmdlets to add details of awards and certificates for inclusion on the Microsoft 365 user profile card. In the article, I mentioned that skills were the first user profile resource added by Microsoft in 2025, and this created a question about why custom skills created with Graph SDK cmdlets don’t show up on the profile card. It’s a good question, so let’s dive in and understand why.
Populating Skills
Microsoft’s People Skills service (introduced in 2025) includes over 16,000 skills that can be attributed to user accounts and displayed on the user profile card. The service uses AI analysis of peoples’ roles and their activity within Microsoft 365 to assign skills to users, Users can then confirm the assigned skills using the Update your profile option on the user profile card. Confirmed skills have a check mark to indicate their status (Figure 1).
Over time, the service might attribute new skills to users. These skills are unconfirmed (no check mark) until explicitly affirmed by the user. People can also add their own skills to the set. These skills are always deemed to be confirmed because a user has added (claimed) the skills.
Adding Skills via the Graph
Organizations can introduce skills data via a People Connector. This scenario covers the situation where an organization has skills data in an external repository like a HR database. The people connector ingests bulk skills information into the Microsoft Graph. Alternatively, the Skills Graph API can be used to update skills information for individual user profiles. Of course, there’s nothing to stop an organization reading information from a source and using that information to update user profiles with the Graph APIs. Here’s an example of adding a skill to a user profile with the New-MgBetaUserProfileSkill cmdlet from the Microsoft Graph PowerShell SDK:
$SkillToAdd = "Microsoft 365 Copilot"
$Skill = @{}
$Skill.Add("allowedAudiences", "organization")
$Skill.Add("proficiency", "Expert")
$Skill.Add("displayName",$SkillToAdd)
New-MgBetaUserProfileSkill -UserId $User.Id -BodyParameter $Skill -ErrorAction Stop
But here’s where the complication arises. Skill data imported via a connector or added using the Graph API is ignored by the user profile card once a Microsoft 365 tenant enables People Skills. When People Skills is active, that service becomes the only source for skills information displayed on user profile cards. The Microsoft documentation says:
“If the tenant opts in to the People Skills service, only skills that originate from People Skills are displayed on the profile card. In this scenario, when People Skills is enabled, skills from people connectors are only available in people search and Microsoft 365 Copilot Chat.”
In other words, when People Skills is in use by a tenant, any other skills data is ignored. On the plus side, skills added via the Graph or connector are used by Microsoft 365 Copilot when asked to find people with a certain skill.
There doesn’t appear to be any technical reason why Microsoft has imposed a block except to defend the People Skills service for some commercial or internal reason. In any case, it’s a silly decision that blocks tenants from being able to take advantage of the People Skills service at the same time as having the option to add individual skills to user profiles via the Graph.
One More Thing
When I discussed adding resources to the user profile card via the Graph, I failed to note that the APIs (and cmdlets) do not check if a user profile already possesses a specific resource before allowing the same resource to be added. Take the example of the Microsoft 365 Copilot skill shown above. It’s possible to run the New-MgBetaUserProfileSkill cmdlet multiple times to add the same skill to the same user profile. Each time a skill is added, the Graph assigns the entry a unique identifier. A human quickly realizes that multiple skills of the same type exists because they see the same display name, but software focuses on the skill identifier, which is different for each entry.
The fix is simple. Check if a resource already exists before you add it again. It’s all just a matter of code.
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.