Content Search Web Part filter by user properties on Multi-Choices field

Question

I'm trying to filter a content search web part by using the current user's office value {User.Office} imported from AD.

I followed Ben N.'s example here: https://en.share-gate.com/blog/filtering-content-with-sharepoint-user-properties-search

In this example, there are two managed props used:

• Target - List column managed property
• {User.Office} - User profile managed property

My Query:

(path:"http://SharePoint/Site/Pages"
ContentTypeId:0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D001C98329396731B49A7CD1E5`5FDC5EB5B* OR ContentTypeId:0x01010A005BE79603E138A9439396512A9967A3BA*)

DisplayHomeOWS=Yes TargetOWSCHCM:{User.Office}

Problem:

when I did a proof of concept with "Target" as a single choice value, everything resolves and I'm able to get the results based on my office location. However, when I changed the "Target" column to a multi-select choice field (Users can have more than one office location), it doesn't seem to resolve anything anymore.

Can anyone confirm that multi-select choice fields are being indexed in the search crawl? If so, can anyone let me know if I'm missing something?

I've run several full crawls after each managed property was added/mapped. Still not positive results.

Thanks in advance!

Answer 1

https://support.microsoft.com/en-us/help/3032761/incomplete-search-results-for-choice-type-columns-with-multiple-values

What caused the problem?

The SharePoint 2013 Search schema creates the crawled property ows_MyChoiceColumn,for the multi-value enabled choice type of column, during crawling/indexing the custom list MyList and it will store the contents as a single value string in the full-text index on the file system.

Similar problems and solutions

You will face the same behavior when using a multi-value enabled choice type of site column but SharePoint 2013 automatically creates a managed property for your site column as described in the TechNet article Automatically created managed properties in SharePoint Server 2013 (http://technet.microsoft.com/en-us/library/jj613136(v=office.15).aspx).

These are the solution steps for a site column with e.g. the name MyChoiceSiteColumn:

Navigate to your Search Service Application administration site and click on Search Schema.

Search for the managed property by entering MyChoiceSiteColumn and click on the retrieved MyChoiceSiteColumnOWSCHCM property to modify the configuration: You have to enable the options Searchable and Allow multiple values Finally save the new managed property with its configuration by clicking on OK

Now start a full crawl or select to re-index your SharePoint site, list or library, which contains the multiple value enabled choice type of column, and wait for the scheduled start of the next continouos or incremental crawl or manually start an incremental crawl.

Answer 2

Thanks, Marko for your response. I was able to figure out the source of the problem. The issue actually didn't have anything to do with the change to a multi-choice field. In fact, it confirms that this field does get indexed and can be used for filtering within a content search web part.

On that note, the issue after hours of troubleshooting had to deal with versioning. The library, by default, was set to allow major and minor versions.

I have a workflow that checks out the item and assigns the appropriate values to the "Target" field. Once target value is assigned, the workflow checks the item back in. The issue is that it can only check it in as a minor version so the search index never picked these items up with the appropriate metadata. Therefore, my cswp never returned any values. Just BLAHHH!

Anyhow, I just set the versioning settings to only store major versions. After doing this, the crawl is now able to index each item at each incremental crawl and now proper results are returned.