Adaptive scopes are good, but what if both policies are implemented? Which one wins?
The scenario for two policies might be: static retention policy is implemented as default retention policy for all sites, and if site require different retention or deletion – it should fall under one of the adaptive scopes and an adaptive retention policy will be applied.
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 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
)
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
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 is the takeaway from this for SharePoint administrators? We would be asked to configure SharePoint the way compliance…
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.
(WIP)
Microsoft recently implemented “Adaptive retention policies” that use “Adaptive scopes”. Adaptive scopes can use “Site Url”, “Site Name” and 100 Refinable Strings from “Refinable String 0″ to ”Refinable String 99”.
How to configure SharePoint the way Refinable Strings are used in the Adaptive retention policies scopes?
Create an indexed site property or “Adaptive Scope Property” with some values. Ensure you property name (key) is unique, e.g.
| Property | SiteRetentionProperty |
| Value | Y10 |
with PowerShell Set-PnPAdaptiveScopeProperty or with Set-PnPPropertyBagValue -Indexed:$true. Examples:
Set-PnPAdaptiveScopeProperty -Key "SiteRetentionProperty" -Value "Y10"Wait until search crawler pics up you site property. Now you have a crawled property.
As you know, Refinable Strings are just pre-created by Microsoft refinable managed properties. So you can select one that is not used(*) and map it to crawled property.
Assign alias so you could easily identify what is the RefinableString55 about.
select one that is not used
select one that is not used is an important moment, as if you select refinable string that is already taken at the site level – there is a conflict. So before configuring pre-created refinable properties at tenant level – I’d recommend to get report on managed properties taken at sites levels. It would be good idea if you agree with sites owners on properties ranges (e.g. from 00 to 99 – reserved for tenant use, from 100 to 199 – available at sites levels). And/or you can – after getting report on managed properties taken at sites levels – reserve enough unused managed properties by assigning aliases e.g. “this-property-55-is-reserved-do-not-use”.
site custom script
If site custom script is enabled (DenyAddAndCustomizePages = false), then site collection admin can change site properties. So if you do not want the property being altered at site level – ensure that noscript site property is enabled (DenyAddAndCustomizePages equals true)
References
(tbc)
As I am a SharePoint person, and retention policies and labels are not a SharePoint engineer responsibility, I do not go to the m365 Compliance Center frequently. Below are My notes for myself on key moments – how to create and configure Office 365 retention labels and Policies at Compliance Center and use labels in SharePoint Online (SPO).
In SPO at each site collection level you can still work with retention policies the old way – create policies under Site Collection Settings – Content Type Policy – and apply policies at library level under Library Settings/Information Management Policy Settings. There is also Site Retention Policy.
But Microsoft is making efforts to centralize and unify such things – so you can specify retention policies in one place and apply them across all Office 365 content (not only SharePoint). That place was called Office 365 Security and Compliance Center (SCC). Later Microsoft separated Security Center and Compliance Center. So currently Retention Policies are under “Microsoft Purview” (former Microsoft Compliance Center) -> Solutions -> “Data lifecycle management”:
To get access to “Data lifecycle management” solution – you need to have a “” or “” roles. SharePoint or Teams administrator cannot access Purview. Even having “Global reader” or “Security reader” an admin will not be able to see “Data lifecycle management” blade. Here is how Microsoft Purview looks like for a Global reader:
Although SharePoint admins usually do not have access to SCC and do not go to Site content, we still need to know how it all works. And labels are recommended way to specify retention in SharePoint, so here we are.
Labels are applied to documents, documents are kept in libraries, and at each library you can “Apply a label to items in this library”.
Labels are created in SCC under Classification. The main part looks familiar to SharePoint people:
You can
after it was created/modified/labelled
Now you need to publish created labels – and that is how you create a policy. I.e. policies are where you specify which labels to which content (Exchange, OneDrive, SharePoint, Office 365 groups)
You can also auto-apply labels based on conditions, like
but as per Microsoft, “It will take up to 7 days to automatically apply the label to all items that match your conditions.”
Note: “trainable classifier” means an AI ML will be used, and as per Microsoft “Creating machine learning rules requires an Office 365 E5 subscription for your organization”
You can do nothing with labels at SharePoint admin center. Labels are created, published and auto-applied at SCC. At each site collection levels site administrators can apply labels.
At site collection settings you can still see “Content Type Policy Templates” and “Site Policy”, but that is not the case. Labels are applied at library level under Library Settings/Apply label to items in this list or library.
where you can select a label to apply for all new items in the library. With
You can also apply the label to items that already exist in the library.
You can also apply (change) label for each single item or multiple selected items under Details pop-up page:
or from under Contect Menu/More/Compliance details:
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 LQL query.
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.