Microsoft recently implemented “Adaptive” retention policies. At step 2 of “Create retention policy” you’ll be asked “Choose the type of retention policy to create”: “A policy can be adaptive or static. Advantage of an adaptive policy will automatically update where it’s applied based on attributes or properties you’ll define. A static policy is applied to content in a fixed set of locations and must be manually updated if those locations change.”

And if you selected “Adaptive” – on the next step you will need to provide the adaptive scope (so at this moment you should already have created your adaptive scopes):

So, let us create your adaptive scopes.
What type of scope do you want to create? SharePoint sites…

And then you’ll have nothing more then set of conditions:

where you can use objects: “Site Url”, “Site Name” and “Refinable String 0″..”Refinable String 99”. Conditions would be “is equal to”, “is not equal to”, “starts with” and “not starts with”. Or you can select “Advanced query builder” and enter KQL query.
Advanced query builder
Advanced query builder allows us to use more site properties then “Site Url”, “Site Name” and “Refinable Strings” and more conditions than “is (not) equal to” and “(not) starts with”.
E.g. we can use “Title”, “Created”, “Modified” site properties and “=”,”:”,”<“, “>”, “<=”, “>=” conditions.
Working queries examples:
created>=2022-07-21
created>12/31/2021 AND modified>=7/31/2022
title:test
SiteTitle:test
RefinableString09:Test*
Not working queries examples:
site:https://contoso.sharepoint.com/sites/test*
RefinableString11 = Birds # (do not use spaces in advanced query)
Path:https://contoso-my.sharepoint.com
Template:STS
Template:"SITEPAGEPUBLISHING#0"
Template:SITEPAGEPUBLISHING*
Query against custom site property (aka property bag value)
You can create custom site property and assign value to the property with
Set-PnPAdaptiveScopeProperty or Set-PnPPropertyBagValue.
Property must be with “Indexed” parameter. Once the property is set up, m365 search crawls site and creates crawled property. Then you map crawled property to some pre-created refinable string managed property. You can assign alias to this managed property.
In my test scenario I used RefinableString09 with alias SiteCustomSubject.
Site property value | Query | result |
Birding | RefinableString09:Bird | does not work |
Birding | SiteCustomSubject:Bird | does not work |
Birding | RefinableString09:Bird* | works |
Birding | SiteCustomSubject:Bird* | does not work |
Birding | RefinableString09:Birding | works |
Birding | SiteCustomSubject:Birding | does not work |
Birding | RefinableString09:Birding* | works |
Birding | RefinableString09=Birding | |
Birding | RefinableString09=Bird | . |
Birding | RefinableString09=Bird* | . |
Birding | SiteCustomSubject=Birding | . |
Query against multi-value property.
Site property value | Query | result |
TestA TestB | RefinableString09:TestA | works |
TestA TestB | RefinableString09 = ‘TestA TestB’ | does not work |
TestA TestB | ??? RefinableString09=’Test10 Test5′ | does not work |
TestA TestB | RefinableString09:TestB | ? |
TestA,TestB | RefinableString09:Test* | works |
TestA,TestB | RefinableString09=Test* | does not work |
TestA,TestB | RefinableString09:Test | does not work |
RefinableString09=TestA | . | |
TestA,TestB | (basic) RefinableString09 starts with test | works |
What is the takeaway from this for SharePoint administrators? We would be asked to configure SharePoint the way compliance/retention people can use Refinable Strings.