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“.
How to configure SharePoint custom site properties the way the retention policies adaptive scopes can consume Refinable Strings?
The steps are:
- Create an indexed site property with values
- Map crawled property to a refinable string managed property
Detailed steps:
Indexed site property
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.
Search schema mapping
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).
(*) Notes
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.
Pingback: Office 365 retention labels and policies for SharePoint ⋆ Vladilen