WIP…
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.
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.
Microsoft recently implemented “Adaptive Scopes” for retention policies”. Before that we had to use “static” scopes only, i.e. we could apply the policy to all sites or to specific selected sites we had to choose manually. With adaptive scopes we can use rules like “This adaptive scope must include all sites with Site Url starts with A or Site name starts with A” and so on. And then we’d apply the retention policy to all the sites in this adaptive scope. This is nice, but actually site Url and site name does not have much to do with sites categorization for the retention policies. How can we implement sites classification to apply different policies to different sites categories? Luckily, when you configure adaptive scopes, you can use Refinable Strings, and refinable strings is something you can configure to have values from custom site properties. So finally we can assign specific value to custom site property and the site would fall under this or that retention policy based on the value we dynamically assigned to the site.
Note: you can also use site properties like date site created or site last modified date in advanced query builder under adaptive scopes – please check “Microsoft 365 Retention Policies SharePoint Adaptive Scopes Advanced Query“.
The steps are:
Detailed steps:
Create an indexed site property or “Adaptive Scope Property” with some values. Ensure you property name (key) is unique, e.g.
| Property | Value |
|---|---|
| SiteRetentionCategory | Y10 |
You can use PowerShell (with PnP.PowerShell module) commands:
Set-PnPAdaptiveScopeProperty or
Set-PnPPropertyBagValue -Indexed:$true. Examples:
Set-PnPAdaptiveScopeProperty -Key "SiteRetentionProperty" -Value "Y10"Wait until search crawler picked 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.
You can assign alias so you could easily identify what is the RefinableString55 about (but aliases do not work in advanced query).
select one that is not used
select one that is not used is an important, bacause if you select refinable string that is already taken at the some 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 arrange with sites owners on properties ranges (e.g. from 00 to 99 – reserved for tenant use, from 100 to 199 – available at sites level search customizations). And/or you can – after getting report on managed properties taken at sites levels – reserve all unused managed properties by assigning aliases e.g. “this-property-55-is-reserved-by-admin-for-tenant-level-config”.
site custom script
If site custom scripts are 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)
If site custom scripts are disabled (DenyAddAndCustomizePages = true), then an admin must enable them before using “Set-PnPPropertyBagValue” cmdlet (then disable again).
“Set-PnPAdaptiveScopeProperty” cmdlet handles this automatically.