SharePoint Search: Amp up the Power

SharePoint search probably isn’t going to do what you want it to right out of the box -- better roll up your sleeves and setup a search schema.

By Cathy Dew

If you use SharePoint as a document management solution, then you probably rely on SharePoint search to discover or locate specific files. In a site or library that houses thousands or even tens of thousands of documents, you should be able to use keywords and metadata terms to find the one document you require. Otherwise, your search can easily turn into a hunt for a needle in a haystack.

However, SharePoint search isn’t just going to do what you want it to right out of the box. On the contrary, if you want a search function that can find specific files in crowded SharePoint libraries, you need to set up and customize the search schema so that it works for you. In other words, you need to turn standard search into power search.

Keeping Control of Your Content Types and Custom Columns

The first step to enabling so-called “power search” in SharePoint is to invest some time in setting up your managed metadata system. Having metadata for each SharePoint document will make those files more searchable. Columns and content types are at the core of SharePoint metadata management.

Think of columns like you would on an Excel spreadsheet. When you create a spreadsheet, each column has a different property, be it a name, a date, a dollar amount, etcetera. The same basic idea is true of columns in SharePoint. A single SharePoint document might have half a dozen different columns. One column is the title. One column is the file type. One column is the author. One column is the date the file was created. Another column might be the date the file was last modified. Each column provides more information about the file in question, making it easier to contextualize and easier to store.

Content types are a way to group different columns together so that they are reusable for a certain kind of document. Say your company uses SharePoint libraries to store a lot of client invoices. You might set up an invoice content type, which itself is a group of columns such as invoice number, customer or client, department, date, etc.

Click To Tweet

Your SharePoint search can easily turn into a hunt for a needle in a haystack.

The content type is convenient for two main reasons. First, every time a user creates a new invoice, the columns they need to fill out are right there. The person doesn’t need to recreate the same set of columns for every new invoice, which saves time. Second, the columns are essentially required for every new invoice that is created or uploaded. As a result, you don’t end up with an invoice that doesn’t have a client tag or invoice number. Content types breed more consistency in the use of metadata, which in turn helps with searchability.

Content types are designed to make life easier in SharePoint, but they can make it more difficult if you aren’t careful. Here are a few tips to keep your content types under control:

  • Only add columns that include data you will have for every file in a specific class (e.g. invoices). Don’t add data just because you have it. Content type columns need to be reusable, and they can’t be if you have columns for data that not every document using the content type will have.
  • Each column needs to be simple and unambiguous. When your end users see a column like “Invoice Number” or “Client,” there is no question of what data needs to be entered there. More complex columns only confuse.
  • Reduce duplication. Don’t ever have two columns that contain the same information, or could contain the same information. Also, don’t have content types that overlap with one another, to the point where a file could belong to both. You need to create a relatively simple system, or your metadata isn’t going to help with discoverability at all.

Crawled Vs. Managed Properties

Simply adding additional content types and columns for your SharePoint documents doesn’t mean all that metadata automatically becomes searchable. The reason is that SharePoint search uses what are called crawled and managed properties to determine what comes up in a search. Each metadata column includes a “property” of a file, but not all these properties are in SharePoint’s search index.

Just like a search engine has a crawler to explore pages on the web, SharePoint search has a crawler to index useful search properties. SharePoint’s search schema will typically crawl everything. These “crawled properties” will include document titles, author names, and virtually any other metadata columns you add to a file or content type.

However, since most SharePoint sites or libraries have many items to search, the fact is that not every crawled property is going to be useful for finding relevant results. As a result, SharePoint’s search index uses a more selective list of properties—called “managed properties”—to display search results. When you create a new column, the data in that column is classified only as a crawled property, which means that it won’t be included in the search index. To make the data from that column searchable, you will need to map a managed property to a crawled property. SharePoint’s crawler will then index that data and make it available for search.

Managing Your Managed Properties

Ideally, using content types in SharePoint will help you create consistency in how your SharePoint documents are tagged and organized. However, sometimes, there will be inconsistencies just because different people are creating and managing content types. For example, say you want to be able to search files based on the client. While some content types will have this column labeled as “Client,” others may have it labeled as “Customer,” “Company,” or “Account”—among several other expressions or variations. Similarly, the “Author” column might be alternatively labeled as “Writer,” “Creator,” “Created By,” “Owner,” etc. in different content types.

Obviously, if you want to search based on author or client, you don’t want to have to create different managed properties for every single variation of those column headings. Luckily, SharePoint allows you to group similar crawled properties under one managed property. If you have content types with columns for “Client,” “Customer,” Company,” and “Account,” all those columns are crawled properties. You can create a managed property for “Client” and then map each crawled property to that managed property. Then, whenever you type “Client:” into the search bar (followed by a specific column name), it will return results not only from columns that are labeled “Client,” but also from all the synonymous columns mapped to the same managed property.

Adding Aliases to Managed Properties

One of the lesser-known features of SharePoint’s search schema is the alias. In most cases, if you want to make a property searchable, you would just create a new managed property in the search schema and then map it to one or more crawled properties. However, the creation of this type of managed property is somewhat limited. SharePoint has seven different “Type” fields for managed properties. These fields include Text, Integer, Decimal, Date and Time, Yes/No, Double precision float, and Binary. When creating a new managed property, the standard way, you can only choose between Text and Yes/No.

Now, normally this kind of limitation isn’t a problem since the majority of columns you want to make searchable are probably text-based anyway. However, if you want to be able to search dates, numbers (employee ID numbers, perhaps), dollar amounts, or other more unusual queries, you will need to create your new managed property by renaming an existing one.

Here is where aliases come into play. SharePoint has a series of what are called “default unused managed properties” that make it possible to query, refine, sort, or otherwise manipulate searches using dates, decimals, integers, and other (mostly numerically based) fields. For example, you want to make dates searchable, or usable as refiners in other searches. You would need to find the existing default unused managed property to make dates queryable or refinable, rename that property with an alias (probably just as “Date”), and then map it to the appropriate crawlable property.

Each default unused managed property can be used with several crawled properties, which means that you can set up a single managed property as a refiner or a queryable property for all your related dates, times, numbers, and more.

To learn the specific steps required for setting up an alias in the SharePoint search schema, go here and scroll down the page.

Get Help with Your SharePoint Search

If you are in the process of turning your SharePoint search function into a power search function, 2Plus2 can help. If you use SharePoint as your document management solution and want to make sure your SharePoint sites and SharePoint libraries are more searchable and easier to navigate, give us a call. We can help you set up your columns and content types, give you a crash course in managed properties and crawled properties, and even help you understand how aliases work and how you can configure them. Go online to schedule a free consultation with our team or call 510-652-7700 today.

Cathy Dew
Cathy Dew – CEO + Information Architect
Cathy focuses the company on our mission – Real results. Every time. Information architect and strategist, Cathy is passionate about making software work well – the function, the feel, the result.
Send me great news