Though search in Microsoft 365 SharePoint is good out-of-the box and you can do a full-text search and refine your results by “File type” and “Last modified”, but what if you want your content be tagged with your custom metadata (e.g. “Article category”), and you want to be able to refine your search results based on this metadata? I’d say it is possible and I’ll provide the solution below. The solution includes working with site term store (creating terms, term groups, term sets), configuring list/library columns and updating site search schema (mapping crawled properties to managed properties).
your organization maintain custom active directory attributes – e.g. Campus Name, Employee Id, Hiring Category etc.
your organization use Microsoft 365 for collaboration
users want to search for custom properties like “Employee id” or refine search by custom properties like Campus Name
What is Microsoft saying
“The following Azure AD user attributes are synced to the UPA.” : (Azure AD attributes) – UserPrincipalName, DisplayName, GivenName, sn, telephoneNumber, proxyAddresses, PhysicalDeliveryOfficeName, Title, Department, WWWHomePage, PreferredLanguage, msExchHideFromAddressList, Manager Respective User profile property display names: Account Name, User Name, User Principal Name, Name, FirstName, LastName, Work phone, Work Email, SIP Address, Office, Title, Job Title, Department, Public site redirect, Language Preferences, SPS-HideFromAddressLists, Manager (here)
Q: “Why isn’t it possible to map additional properties for UPA synchronization to sync from Azure AD to the User Profile Application?” A: “UPA synchronization is limited to a preconfigured set of properties to guarantee consistent performance across the service.” (here)
“You can make the following attributes from Azure Active Directory (Azure AD) visible on users’ profile cards. These attributes are not case-sensitive: UserPrincipalName, Fax, StreetAddress, PostalCode, StateOrProvince, Alias” (here)
“You can add any of the 15 Azure AD custom extension attributes to users’ profile cards… Custom properties are not searchable and can’t be used to search for people across Microsoft apps and services.” (here)
Solution
It takes a few steps to solve the problem:
create a custom property under SharePoint Online User Profiles service
synchronize AD/AAD attribute with SPO User Profile custom property
configure Search Schema – map crawled property to managed property
Detailed:
Create a custom property under SharePoint Online User Profiles service
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – more features – User Profiles – Manage user properties – New Property
Configure custom property according to your needs, – ensure “Policy Settings” “Default Privacy Setting:” Everyone is selected – ensure “Search Settings” “Indexed” is selected
Hint: you can fill this property for some user profiles – for search to pick it up and crawl the property – so you could configure search schema mapping before synchronizing property from Active Directory
Synchronize Active Directory attribute to SharePoint Online User Profile
That would be a custom solution – e.g. scheduled PowerShell script. You can host this script in Azure Functions if you sync Azure AD attributes to SPO or use on-prem machine if you need access to local AD.
PowerShell Script example (TBP)
Configure Search Schema – map crawled property to managed property
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – More features – Search – Manage Search Schema
Select Crawled Properties and ensure search picked up your custom property and crawled it – you should see your property name under Category: People.
Full-text search and/or query-based search
If you want your custom property is generally available in full-text-search – i.e. user simply enter value in a search bar and gets results – typical scenario might be an employee id – here are the steps (under Search Schema)
create a new managed property
for Full-text search
select Searchable
under Advanced searchable settings – select Full-text index: PeopleIdx
for Query-based search – select Queryable and Retrievable
map this managed property to crawled property
Free-text search: you just enter what you search for into search bar and click search.
Query-based search allows you to use KQL – e.g. you are searching for keyword “PowerShell” with full-text search, but want only people with PowerShell skills located in a specific building or campus – search query might look like “PowerShell campus:Stanford”
Refine search with custom property
If you want to be able to refine your search with custom property – in this case the steps are (under Search Schema):
under Managed Properties – select a refinable string property that is not taken (not mapped) – e.g. RefinableSting53
setup alias – so you could refer to this RefinableSting53 by meaningful name
Update (Apr 2024): It seems like Microsoft changed this behavior for Microsoft 365, so consider this article as an obsolete. Though it is possible that content is still relevant for on-prem versions of SharePoint server.
Scenario:
You have a list (or a document library) in SharePoint Online. You can search through the list but some fields (or document properties) like “Description”, “Subject”, “Author”, “Owner”, “AssignedTo”, “Created”, “CreatedBy” are not searchable.
Cause:
Crawled properties are mapped to non-searchable managed properties. So this is by design. Check Microsoft’s “Overview of crawled and managed properties in SharePoint Server” (we do not have this document for SharePoint Online, so we have to rely on this doc; though you can go to your Search schema in SPO to verify). You see some pre-created managed properties do not have “Searchable” option enabled.
Solution:
(See below for details, as this is still not finished:)
Prove:
I have created a new SPO site test78, a new list Test11 and created (not added from existing) a custom field “Description” to the list:
I also created “Description2” column the same way. No data is added to the list so far.
Search schema looks like:
for Description managed property:
mapping:
Notice that “Description” managed property is not searchable and “ows_Description” crawled property is mapped to “Description” managed property.
Searching for “ows_Description” crawled property gives me:
and that’s OK, as we have no data in the list so “ows_Description2” crawled property does not exist.
Now let me add some data to the list:
and wait a few minutes while continues crawl grabs data.
You can see:
Title and Description2 are searchable, but we are not able to search through “Description” field content.
Explanation
Actually this is by design. Microsoft: “The index only includes content and metadata from the managed properties”. (Maybe Microsoft tries to protect their resources from overloading or maybe they protect us from irrelevant results, but including entire document content in full-text search and at the same time not including properties like Document Subject – this does not make sense to me). So the sad fact is list column “Description” is mapped to non-searchable managed property by default.
“Searchable” means: “…The content of this managed property is included in the full-text index.” I.e. if the property is not searchable – “The content of this managed property is not included in the full-text index.” => that’s by design.
But – the good news – the property is Queryable! Queryable “Enables querying against the specific managed property”.
E.e. “Description:Descr1*” query should work. And it works:
“Description2:Descr*” query should not work as we did not map Description2 property to any managed properties, so we can find content via full-text search but cannot find under managed property:
Solution
Option #1. Use queries like “Description:TextToSearch” (check also SharePoint KQL).
Option #2. Do not use name “Description”. Choose something else like “Short Description” or “Case Description”
Option #3. Use existing site column “Description” from group:Custom Columns. It’s “single line of text” though. Note: “SharePoint Server Standard Site Collection features” must be activated.
The thing is it’s internal name is “CategoryDescription” and display name is “Description”. So if you add this column to the list – the content will be searchable:
Option #4 Create a new site column, name it e.g. “DescriptionSrchblClmn”. Add this column to the list from existing site columns. Rename it to “Description”.
Option #5. Create your own managed property (e.g. “DescriptionSearchable”), make it searchable and map it to “ows_Description” crawled property.
ensure crawled property has “Include in full-text index” option ON:
NB: changing search schema affects other site lists/libraries.
Remember: if you made a change in search schema, run “Reindex site” under Site Settings -> “Search and Offline Availability”. It’s like on-prem “Full crawl” but works at web level.
If you are managing SharePoint search, specifically if you are customizing SharePoint search schema, especially in SharePoint Online (Office 365) – you know how slow it works and how tiresome it is to “Search for a crawled property name”.
Recently I found out that wildcard works. No, even two wildcards work!
In this example I need crawled property started from ows and contains doc and type:
The following solution is for Classic Search only.
What I did is:
User profile services -> Manage User properties: create custom property like “HideFromPeopleSearch”, boolean, do not allow users to edit value, Indexed
Client-side PowerShell script using PnP library:
Connect-PnPOnline -Url https://domain-admin.sharepoint.com
…
$nonPeople = Get-ADUser -filter … # based on what’s in your AD and how you separate people and non-people accounts
foreach($account in $nonPeople) {
Set-PnPUserProfileProperty -Property ‘HideFromPeopleSearch’ -Value ‘True’ -Account $account.UserPrincipalName
}
SearchCenter -> Site Settings -> Search Schema: use any pre-created RefinableString managed property (e.g. RefinableString33), add mapping to crawled property people:HideFromPeopleSearch,
SearchCenter -> Site Settings -> Search Query rules: Local People Results, new Query rule, change ranked results by changing query, {searchTerms} -RefinableString33=True
