Secret SharePoint: Search Power05 Jul 2018
SharePoint’s search engine is powerful. It indexes content and properties. It includes ranking engines that help float the information you really want to the top of the list. However, there are ways you can structure your query to get even more relevant results.
Solution 1: Search by Property
Full-text search, like the kind SharePoint provides, is a powerful tool. It allows you to reach into the bowels of a document to find that redeeming nugget and locate it through a simple query. However, sometimes the term you’re looking for is too common, too generic, or too simple. It’s those times when you long for the simplicity of a database query or the ability to filter the results by a column. SharePoint mitigates this by providing search refiners in the left-hand side of the search results page. These refiners allow you to specify one of the values displayed from a particular field, not everywhere in the document.
Refiners and Managed Properties
Refiners are based on managed properties; in fact, they are simply managed properties with special settings, which have been set to make the search process easier. Managed properties are properties that have been configured in SharePoint so that they’re individually searchable. For instance, you can search within the Author property exclusively — and because it’s a default refiner, it even displays itself on the left-hand side of the search results page with the list of the most popular values for the Author field.
Managed properties can contain the value from one or more than one crawled properties. Crawled properties are the properties in the documents that are discovered by the crawler while it’s indexing the information in documents. They include properties of the document, like title and author, as well as custom properties that have been set. Word, for instance, allows you to set properties with any name you would like as a part of the document. The crawler also includes any columns that are specified in SharePoint for the document.
Managed properties are defined with a name, and that name can be used to search information only in the crawled properties that are mapped to the managed property. Searching specific to a managed property is simple. Include the name of the managed property followed by a colon if you want to find the value in the property. For instance, “author:Bogue” finds all items where Bogue is in the author managed property. In this case, that could have come from an Author field in SharePoint or from a document where it was included in the author property.
If I wanted to be more specific, I could replace the colon with an equal sign, and I would be looking for an exact match in the property. The same query would be “author=Bogue”, but it wouldn’t match any entries in my environment. That is because it’s looking for an exact match, and my name always appears as “Robert Bogue”, “Robert L. Bogue”, or “Bogue, Robert” in my environment, and “Bogue” isn’t an exact match for any of those.
Solution 2: Quotes
Searching for a set of words doesn’t convey meaning or, by default, any proximity between the terms. In other words, if I search for Robert Bogue (without quotes) the resulting search will return items where both the terms Robert and Bogue are present in the results. That can work sometimes, but sometimes it will accidentally pick up the arguments that Robert Smith is making about Bogue sound. (Yea, there is a Bogue sound.) To convey to search (SharePoint or otherwise) that I want the words to appear in exactly the same order as provided in the search, I add quotes around them. So “Robert Bogue” will not return results from Robert Smith’s work at Bogue sound, because Robert and Bogue won’t appear together in that document. However, this also means that any document that contains “Bogue, Robert” won’t appear either, because the words don’t appear in the correct order.
If you wanted to capture Bogue, Robert without capturing Robert Smith’s work, I could use the NEAR keyword — or the tilde (~) character. This query would look something like “Robert ~ Bogue” and will reject most of Robert Smith’s work while accepting all of the documents that I’ve authored, even if my name appears as “Bogue, Robert.”
Solution 3: Remove Unwanted Results
Up to this point, we’ve been adding terms to narrow results. We’ve discussed filtering by adding more terms. However, sometimes it’s better and easier to reject items based on how you know that they’re not what you want. For instance, if I know I’m not looking for Bogue sound, I could remove all of the results with sound in it by preceding sound with a minus (-), like this “Bogue -sound.” This will quickly filter out the unwanted results — and unfortunately remove some desirable ones as well.
It turns out that SharePoint can’t tell the difference between sound as in noise and sound as in water. That means it will unintentionally exclude items which use the word “sound” even if we’re not talking about Bogue sound. There are two solutions to this. First is to use our quotes trick. A query that includes Bogue and “-“Bogue sound”” will return items with Bogue but not with “Bogue sound.”
An alternative is to know that Bogue sound is in North Carolina so you could include “-NC”. Of course, that presumes that the document you might be looking for doesn’t include a reference to North Carolina and the documents you want to exclude will have North Carolina’s state abbreviation.
Solution 4: Wildcard
By default, SharePoint search will do stemming of words. It will expand “run” to “running”, and even “ran”. It will leverage knowledge of synonyms to try to be more inclusive of things that you might want but didn’t specify exactly — if you don’t use quotation marks or an equal sign to require that it match exactly.
However, SharePoint won’t, by default, automatically expand every kind of variation. In particular, files that are named without spaces won’t have a word breaker (space) to cause SharePoint to see the words as separate. A file named “SharePointFile.docx” won’t be found if you search for SharePoint, as “SharePoint” doesn’t — from its point of view — exist as a distinct word. To fix this, we can tell SharePoint search to find any files where there is a word that starts with what we are searching for. We signal this to SharePoint by including an asterisk after the word. So to find SharePointFile.docx, we can search for “SharePoint*”. This will return anything in the system where there is a word that starts with SharePoint.
It’s important to note that you must include the asterisk at the end of the word. This only works when you know the start of the word you’re looking for. This is particularly useful when you know only how something starts but not the complete number or term.
About the Author
Robert Bogue is a thought leader on all things SharePoint and an engaging presenter who speaks at events around the world. Rob has been awarded the Microsoft MVP designation fourteen times and earned recognition as a Microsoft patterns & practices Champion. Rob holds certifications from Microsoft: MCPD, MCITP, MCTS, MCSA: Security, MCSE, as well as CompTia: A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+. Rob also served as a team member for the SharePoint Guidance. He is the author of 25 books. Robert is committed to “making the complicated simple.” Find out more about SharePoint made simple at www.SharePointShepherd.com and get all the SharePoint secrets and more by visiting www.ThorProjects.com/content. You can also contact Rob at Rob.Bogue@ThorProjects.com.