Basic query is available as GUI:
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
modified>1/31/2023
created>12/31/2021 AND modified>=7/31/2022
created<=2020-11-15 OR modified>2023-02-06 (?)
created<=2020-1-15 OR modified>2023-01-31 (?)
created<=11/15/2020 OR modified>1/31/2023
title:test
SiteTitle:test
RefinableString09:Test*
RefinableString09<>Test
RefinableString09=Birding AND RefinableString08<>Included
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*
? RefinableString09<>Birding AND RefinableString08:Official
modified>31/1/2023 (should be like modified>2023-01-31
)
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 | works |
Birding | RefinableString09=Bird | does not work |
Birding | RefinableString09=Bird* | does not work |
Birding | SiteCustomSubject=Birding | does not work |
RefinableString09<>Birding | works | |
RefinableString09=Birding AND RefinableString08<>Included | works |
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 |
TestA,TestB TestA;TestB TestB TestA TestA TestB | RefinableString09:TestB | works |
TestA, TestB TestB,TestA TestA TestB | RefinableString09=TestA | does not work |
TestA,TestB | (basic) RefinableString09 starts with test | works |
Some more findings
Modify adaptive scope
If you need to modify adaptive scope – you’d better delete it and create a new one. The reason – if you want to validate what sites are included in scope with GUI – via button “Scope details” – you want to see only sites that are in scope, but that’s not the case when you modify the scope, because if you modify the scope – you’d see sites that are not in scope with “Removed” status.
Alternatively you can use filter to filter out removed from scope sites.
what else?
What is the takeaway from this for SharePoint administrators? We would be asked to configure SharePoint the way compliance…
Pingback: Adaptive scopes Retention Policies Data Lifecycle Purview ⋆ SharePoint Vlad