How to Search Across SharePoint Contact Lists

Search is one of the most important topics in SharePoint usage. However, it is often overlooked, especially in small projects or at initial project planning stages.

Let us consider a quick search example in the SharePoint Online list and various search problems which the user/administrator may encounter. Let’s create a contact list and name it TeamContacts.

Now we fill some data in the list:

Let’s type a last name in the search bar and press Enter. And here we got no results, nothing has been found:

For a person who is just started his acquaintance with SharePoint (either for a standard user), it is difficult to understand why the search does not work.

Lost in thought, the user takes a coffee break, then returns to work and searches for another string. Now the result unexpectedly appears:

As we can see, the search started working properly, but it took some time. The quick search box does not filter items directly from the data already contained in the list. Search is performed over the indexed data by Search Service (Manage Crawling in SharePointServer 2013).

Without going into details of data crawling, the user rejoices at the search result. Then he types the search field with the name of the company (column Company), and nothing happens again. He tries to fill in the Home Phone in the field, and the search is working, tries to type Business Phone – and it does not work, the same thing happens with the Company column.

So let’s learn more about data crawling. Crawled properties and managed properties are essential parameters for crawling and displaying search results.

Crawled properties are metadata that is extracted from documents during crawls. Metadata can be structured content (such as the title or the author from a Word document), or unstructured content (such as a detected language or extracted keywords). Managed properties are attributes that determine how the contents are shown in search results. Crawled properties are generated automatically. A managed property can be also created automatically or created by the user. Crawled and managed properties for site columns are automatically mapped. Managed properties for list columns require manual mapping. There are also the default managed properties. For each managed property that by default is mapped to one or several crawled properties, existing crawled properties are listed in the mapped crawled properties column. List of them you can find there — Overview of crawled and managed properties in SharePoint Server 2013

So let’s go back to our example and examine crawled and managed properties compiled for Home Phone and Business Phone columns. Open Manage Search Schema on the Search settings page:

Then click on the link “Crawled properties.” Type the word “phone” in crawled properties field and click the green button to display properties that contain the word “phone” in their names.

So we have found many properties that contain this word, but we need to define which of them are related to Business Phone and Home Phone columns.

SharePoint has name convention for automatically created managed properties. Read more: Automatically created managed properties in SharePoint Server 2013
Home Phone and Business Phone have the following crawled и managed properties:

ows_HomePhone (no managed properties)
ows_q_TEXT_HomePhone (managed: HomePhoneOWSTEXT)
ows_WorkPhone (managed: WorkPhoneOWSTEXT)
ows_q_TEXT_WorkPhone (managed: WorkPhoneOWSTEXT)

In SharePoint 2010, crawled properties were known as ows_InternalColumnName. In SP2013/Online names, the convention was changed: ows_q_{Data Type Code}_{Site Column Internal Name}.
It remains unclear why the managed field is configured for ows_WorkPhone only, and the same option is not accepted for ows_HomePhone. Anyway, in SharePoint 2013, managed properties are created automatically only for ows_q_{Data Type Code}_{Site Column Internal Name}.
Let’s skip the details of all possible crawled и managed properties settings and pay attention to the two settings which make column content available for search. For crawled properties, there is the setting Include in the full-text index.

For managed properties, there is the setting Searchable

The table below describes the dependencies of content showing in search results:

Crawled Property		Managed Property
Column name	Not included in Full text-index	Searchable	Not Searchable	Column Searchable
x				✓
	x			✗
x		x		✓
	x	x		✓
x			x	✗
	x		x	✗

In our Contact List example, we have the following characteristics in the Home Phone Column:

ows_HomePhone — Include in the full-text index: TRUE (no managed properties)
ows_q_TEXT_HomePhone —  Include in the full-text index: FALSE
HomePhoneOWSTEXT — Searchable: FALSE

If a crawled property has no managed and parameter Include in the full-text index is true, this property will be shown by searching. That is why we have easily found phone numbers from the Home Phone column.

Settings for Business Phone:

ows_WorkPhone — Include in the full-text index: TRUE/
ows_q_TEXT_WorkPhone — Include in the full-text index: FALSE
WorkPhoneOWSTEXT  — Searchable: FALSE

As we can see, the managed property is compiled for both crawled properties, so it is not available for search.

The solution is the custom creation of managed property: create a managed property (MyWorkPhoneOWSTEXT), set true for the Searchable option, and add mapping to the managed property (ows_WorkPhone). Another option is deleting crawled property ows_WorkPhone from the mapping fields of managed property WorkPhoneOWSTEXT.

So what do we have now in search results?

Searching is enabled for Business Phones as well as for other fields.

Search is one of the most important services in SharePoint, but sadly, many possibilities of its functionality are not described in detail. We hope this article was useful for you.