Phone numbers search - where the answer is "It depends"
A question I get very often when assisting customers with People Search is why they can't search for phone numbers.
The answer is that they in most cases CAN search for phone numbers. However, it might not be as straightforward as they would like.
The primary reason searching for phone numbers is difficult is that we as humans prefer that phone numbers are displayed in a form that is easy to read and remember.
For instance, a US phone number will often be displayed as +1 980 555 0101, and those spaces really can mess up the search. More on this later.
In some cases, the KQL has been twisted in such a way that you can't search for phone numbers:
I searched for Joni, and copied her phone number.
But I get no results?
I then update the query to: FirstName:{subjectTerms} OR MobilePhone:{subjectTerms}
But still no results, what gives?
Checking the UPA reveals that Joni doesn't have a Mobile nor Home phone number.
OK, so the query should be like this perhaps:
FirstName:{subjectTerms} OR WorkPhone:{subjectTerms}
Using the query text +1 980 555 0101 it returns no hits.
Looking at the query sent to the API reveals that it is transformed into
FirstName:+1 980 555 0101 OR WorkPhone:+1 980 555 0101
Ouch, not a well-formed query.
The final query will in this case look like this:
(FirstName:({subjectTerms}) OR WorkPhone:({subjectTerms})* )
and the resulting query in the API call like this:
(FirstName:(+1 980 555 0101) OR WorkPhone:(+1 980 555 0101)* )
Another option is to abandon the specific search and use a more generic query: {subjectTerms}*
(However, this might find matches in unexpected properties)
Query text resulting query Hits
joni joni* 1
+1 980 555 0101 +1 980 555 0101* 1
+1 980 +1 980* 1
+1 9 +1 9* 6
0101 0101* 0
Sorry, SharePoint search can only handle "starts with" wildcards, not "ends with"
Yet another approach is to use the phone number properties for display purposes only, and create your own User Profile properties, like "WorkPhoneAsText" which contains the WorkPhone value stripped for spaces and prefixes.
I have primarily used it with customers that used the last 4 digits like a local extension, and would therefore have a "LocalExtension" property in the UPA and a matching managed Property.
