Additional RefinableString* Managed Property Variants in the Search Schema in SharePoint Online
It would seem like the simplest thing in the world: show results in the PnP Modern Search Results Web Part in alphabetical order. My wanting to do this led to multiple conversations with my search guru Mikael Svenson (@mikaelsvenson) and the uncovering of some really useful variants on RefinableString in the SharePoint Online Managed Properties.
The new(ish? – it’s not clear how long they have been there) pre-created Managed Properties which are variants of RefinableString are now documented in Manage the search schema in SharePoint – SharePoint in Microsoft 365 | Microsoft Learn. Until I offered some updates recently, these variants weren’t in the article. I’m not sure I’d ever found this article before, but it seems to be the canonical list of Refinable Managed Properties, along with a lot of useful information about the Search Schema.
The new (to me, anyway) ones are in the last four rows of the following table in that article:
| Managed property type | Count | Multi | Query | Search | Retrieve | Refine | Sort | Managed property name range | Notes |
|---|---|---|---|---|---|---|---|---|---|
| Date | 10 | – | Query | – | – | – | – | Date00 to Date09 | |
| Date | 20 | Multi | Query | – | Retrieve | Refine | Sort | RefinableDate00 to RefinableDate19 | |
| Date | 2 | – | Query | – | Retrieve | Refine | Sort | RefinableDateInvariant00 to RefinableDateInvariant01 | * |
| Date | 5 | – | Query | – | Retrieve | Refine | Sort | RefinableDateSingle00 to RefinableDateSingle04 | |
| Decimal | 10 | – | Query | – | – | – | – | Decimal00 to Decimal09 | |
| Decimal | 10 | Multi | Query | – | Retrieve | Refine | Sort | RefinableDecimal00 to RefinableDecimal09 | |
| Double | 10 | – | Query | – | – | – | – | Double00 to Double09 | |
| Double | 10 | Multi | Query | – | Retrieve | Refine | Sort | RefinableDouble00 to RefinableDouble09 | |
| Integer | 50 | – | Query | – | – | – | – | Int00 to Int49 | |
| Integer | 50 | Multi | Query | – | Retrieve | Refine | Sort | RefinableInt00 to RefinableInt4 | |
| Yes/No | 4 | – | Query | – | Retrieve | Refine | Sort | RefinableYesNo00 to RefinableYesNo04 | |
| String | 200 | Multi | Query | – | Retrieve | Refine | Sort | RefinableString00 to RefinableString199 | |
| String | 40 | Multi | Query | – | Retrieve | Refine | Sort | RefinableStringFirst00 to RefinableStringFirst39 | * |
| String | 10 | Multi | Query | – | Retrieve | Refine | Sort | RefinableStringLn00 to RefinableStringLn09 | ** |
| String | 50 | – | Query | – | Retrieve | Refine | Sort | RefinableStringWbOff00 to RefinableStringWbOff49 | *** |
| String | 50 | Multi | Query | – | Retrieve | Refine | Sort | RefinableStringWbOffFirst00 to RefinableStringWbOffFirst49 | *, *** |
* Mappings to crawled properties – Include content from the first crawled property that is not empty, based on the specified order.
** Language neutral word breaker
*** Complete Matching
As you can see, each of the additional RefinableString* Managed Properties has something a little different about it, as indicated in the Notes.
Need to know more? Feel free to ask your questions in the comments.
Resources
- Manage the search schema in SharePoint – SharePoint in Microsoft 365 | Microsoft Learn
- How Do Site Columns Become Managed Properties – Thus Available for Search? | Microsoft Learn
- Introduction – PnP Modern Search (v4) (microsoft-search.github.io)
- Sort by Filename · Issue #2351 · microsoft-search/pnp-modern-search (github.com)
Updates
- 2024-11-21 – Added Yes/No row for RefinableYesNo00 to RefinableYesNo04
Hey,
Interesting read. Would you recommend using these as opposed to the standard pre-defined RefinableString001 variants? I’m having real trouble getting PnP modern search to even see any of these RefinableString check box options in the selected properties drop down. Perhaps I could re-map my crawled site columns to the new RefinableStringFirst001 and run another full crawl.
Thanks!
@Edd:
Each of these variants provide a different pre-wired configuration, so you’d only want to use them if they met your specific needs.
Note that you must have created content with those Site Columns populated before the Crawled Properties will appear for use in mapping to Managed Properties. Only after that – and with another crawl – will you see those RefinableStringxx Managed Properties in the PnP Modern Search Web Parts. It’s a string of events which has to happen in the right order, which is really more the underlying search technology than PnP Modern Search.
M.
Great – thanks for the clarification. I’ve certainly followed these steps in this exact order, but unfortunately, the managed properties (RefinableStringXX) and so on, never appeared in my PnP modern search results web part, selected properties drop down. I wonder if there may be a clash if crawled properties are mapped to the same RefinableStringXX value but in a different site collection.
The joys of simple search functionality!
Cheers,
Edd
@Edd:
The RefinableStringxx Managed Properties ought to show up in the dropdown list, but you can also manually type them in the box and they will be retrieved – assuming they have values which have been crawled.
M.
Thank you for the confirmation. I’ve tested this on another tenancy and the properties as you mention, show up. The problematic tenant I’m working on must have other search related issues, or it could be because I do not have SharePoint admin permissions potentially.
Is it possible to use a refinablestring with language neutral tokenization?
Marc – such a thorough and informative article. Thanks. Quick question for you if you don’t mind? I have configured things as follows:
1. Create a multi-value person column in a SP list/library.
2. Map the corresponding OWS_Q_USER_xx crawled property to a RefinableStringXX managed property.
3. Use that managed property in a Modern Search v4 filters web part.
Whilst it works to a degree, the filter shows a whole load of user information for each filter value, an example is shown below:
[email protected] | LastName, FirstName | ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF123456 i:0#.f|membership|[email protected]
Hardly a nice user experience. Just wondering a) if you’ve encountered this scenario? and b) whether you have any suggestions on how to render the filter value more elegantly?
This is probably more of a question for the v4 Modern Search development community but thought it worth running past you, too.
@Joe:
Rather than mapping OWS_Q_USER_xx to the Managed Property, use ows_XX. OWS_Q_USER_xx contains the entire user object, which is why you’re seeing the additional information.
M.
Appreciate the reply Marc. I have tried that already and whilst it does only show the user name (LastName, FirstName), the trouble comes when multiple users are selected. For instance, if document X’s multi-value person column is tagged with John Doe AND Jane Doe, and document Y’s multi-value person column is tagged with just Jane Doe, using RefinableString mapped to the OWS_xx the search filter results in two filter values that look like this:
– Doe, Jane; Doe, John (1)
– Doe, Jane (1)
What I require is that the filter looks like this:
– Doe, Jane (2)
– Doe, John (1)
It seems that using the OWS_xx crawled property just concatenates the users if multiple people are seleceted.
Really useful document, however, I can’t get the RefinableDateInvariant to work the way I understand it should. I’ve mapped 2 properties to it, a custom date property and CreatedTime (which is a crawled property for Created). My understanding is if the custom property is null it’ll default to the Created Date, but it’s only getting the custom value until it finds one without it and then the crawl stops.
Am I missing something?
@James: If it’s just the fallback you’re looking for, you can use RefinableDatexx, listing the date Crawled Properties in the order you want them to have. TBH, I can’t remember what the Invariant part of the Managed Properties means!
Hi Marc, if I understand it correctly, just RefinableDatexx is multi-value, so that’d store both my custom property and the CreatedTime, if an item has both, whereas the invariant will only store one. The custom property if it can, the CreatedTime if it can’t. But that doesn’t seem to work.
I’ll do a test with the regular refinabledate just to make sure though.
Hi Marc, on further investigation I think I’m just having a problem with the out of the box CreatedTime property. Even though it is mapped to Created it’s content is always null. Which then has the knock-on effect that my RefinableDateInvariant never picks up the fallback value, because it’s always null