Microsoft has been working on both classic and modern scenarios for Microsoft Search, and evaluating existing solutions to determine the best way to support query variables. This post is not exclusive to Microsoft Search, and the same technique can be used with any SharePoint classic search experience. The only difference is the type of query variables that are supported for each experience.
For supported query variables in Microsoft Search modern experiences see https://learn.microsoft.com/en-us/microsoftsearch/manage-verticals#profile-query-variables.
For supported query variables in classic search see https://www.techmikael.com/2014/05/s15e03-query-variables-constant-trouble.html.
Solution
The sample case solution provide an option to filter search results down a city. All items are tagged with a managed property City to allow for the filtering. On the SharePoint page of the solution the user can pick their own or a specific city. When picking their own, no query parameter is passed with the city. When picking a specific city the user is sent to a vertical in Microsoft Search passing the city value as a query string parameter:
_/layouts/15/search.aspx/verticalname?City=Helsinki
Which brings us to the query template to use:
{searchTerms} {?City:{Request.City} NOT UNIQUESTRING}{?City:{Profile.positions.detail.company.address.city}}
To see what properties you can use for a Profile query variable, view the output of https://graph.microsoft.com/beta/me/profile in e.g. Graph Explorer. For our test case the City location for a person is available via the query variable {Profile.positions.detail.company.address.city}.
What the above query template achieve is: If a query string parameter City is present, this will be used as part of the query. If not present, the City value of the logged in users profile will be used instead. The {?} notation means that if a query variable is missing, the part enclosed within the braces will be removed all together from the template on evaluation.
I’m using a trick with UNIQUESTRING (which could be any random unique string not present in the search index) to invalidate the last part of the query if we have a query string parameter in the URL. It adds invalid KQL sort of for a property which does not exist, and is thus ignored.
Let’s add some examples to illustrate the evaluation where the ignored part of the query is highlighted in yellow, and the inclusion part in green. The user’s profile value for city is Oslo.
Scenario 1 – Click on Oslo
- ?City=Oslo
- Users City=Oslo
Ending query: City:Oslo NOT UNIQUESTRINGCity:Oslo
Scenario 2 – Click on Helsinki
- ?City=Helsinki
- Users City=Oslo
Ending query: City:Helsinki NOT UNIQUESTRINGCity:Oslo
Scenario 3 – Click on My City
- ?City=<missing>
- Users City=Oslo
Ending query: City:Oslo
Scenario 4 – Click on Helsinki (and missing a city in the profile)
- ?City=Helsinki
- Users City=<missing>
Ending query: City:Helsinki NOT UNIQUESTRING
Scenario 5 – Click on My City and missing a city in the profile
- ?City=<missing>
- Users City=<missing>
Ending query: <empty>
And that’s all there is to it. By matching values on a users profile with values on other data you can create quick navigation and filtering scenarios. By adding SPFx into the mix even more control and logic can be built around the search results pages and passing in values.
