SharePoint Advanced Management includes Inactive Site Policies under Site lifecycle management. Effective content lifecycle management is a key pillar of SharePoint governance. It plays a vital role in optimizing storage, preserving data integrity, and ensuring regulatory compliance. By systematically removing inactive or outdated sites, it also enhances security. Additionally, it supports successful Copilot implementation by ensuring that the information accessed is both accurate and current. So, how exactly this Inactive site policy works and what is the difference between Entra Id groups expiration policy and SharePoint Inactive Site Policy.
SharePoint Inactive Site Policy vs m365 Groups Expiration Policy
The Groups Expiration Policy has been a feature of Azure AD (Entra ID) for quite some time. It is included at no additional cost. This policy automatically notifies group owners about upcoming expirations and provides options to renew or delete the group. Since all self-created Teams teams and Viva Engage communities are backed by SharePoint sites and managed through Microsoft 365 Groups, this policy also plays a significant role in SharePoint governance ensuring that information stored in SharePoint remains current and properly maintained. I have an article Microsoft 365 group expiration policy deep dive.
Inactive Site Policy is a feature of SharePoint Advanced Management (SAM), which is an add-on and require premium SharePoint license. It also Identifies inactive sites, Sends notifications to site owners and can automatically archive or make sites read-only. Sound like very similar to to groups expiration policy.
Key differences
Feature | Groups Expiration Policy | Inactive Site Policy |
---|---|---|
Where to configure Who can configure | Entra Id Groups Admin | SharePoint Admin center SharePoint Admin |
Scope (policy is applied to) | Microsoft 365 Groups (including group-based sites, like teams, yammer) | SharePoint Sites (including both – group-based and non-group-based sites) |
Who is notified | Group Owners | Site admin (group owner), site owners (*) TBC |
Notifications come from email | msgroupsteam@microsoft.com | no-reply@sharepointonline.com |
What if resource is active | group is automatically renewed, no emails sent | policy is not triggered against active sites |
Can admin download report (list of inactive groups/sites) | No | Yes |
Period of inactivity configuration | Configured in days, should be greater than or equal to 30 days | Options are: 1, 2, 3 or 6 months |
Actions available (Options provided) to a resource owner | renew the group delete the group | certify site learn how to delete a site |
What happens with resources owner did not take action (or with orphan resources). | Notifications is sent to a specific email address, group is deleted | site is archived or set to read-only or nothing |
Inactive site policy user experience
Here is how the email notification looks like:

Note that
The email subject includes “Action required” and site title (name).
It always says “… has been inactive for more than a month” even if the policy configured for “6 months”.
It shows SharePoint logo, which might mislead “teams-oriented” users.
Site title is not clickable, so site admin/owner cannot just click site link but have to navigate to site manually.
When user clicks button “Certify site” – a message “The action completed successfully” pops up at the bottom of the email for a few seconds and then disappears. The email itself does not change, so when a user opens the same email again – there is no visual evidences the action was taken.

At the bottom of the email Microsoft mentions tenant name.
The email template is the same for all kinds of policies – it does not matter if the policy action is configured configured as “do nothing”, or to automatically enforce archive site or set it to read-only. I.e. email just says “Select Certify site to confirm if it’s still in use, or consider deleting it if the site is no longer needed.”. Email does not inform users that site will be set to read-only or archived.
Also there is no link where a user can get more info on the subject, but Microsoft says that inactive sites policy email template will be customizable – in the Site lifecycle management policies v2 expected summer 2025.
Admin – Inactive sites report
You can download a csv report of inactive sites generated by policy.
Report includes fields:
Site name, URL, Template, Connected to Teams, Sensitivity label, Retention Policy, Site lock state, Last activity date (UTC), Site creation date (UTC), Storage used (GB), Number of site owners, Email address of site owners, Number of site admins, Email address of site admins, Action status, Total notifications count, Action taken on (UTC), Duration in Read-Only.
There is no GUI to see the list of inactive sites (you can only download a csv file), but there is a magic button “Get AI insights”.
Get AI insights
Here are insights I have seen so far:
- Inactive sites with significant storage usage
- Multiple sites owned by the same account
- Sites with Multiple Owners
- Sites inactive for over a year
Inactive sites policy behavior
Policy sends emails immediately after policy activation. That means if you have thousands of inactive sites you might hit a 10k exchange limit of daily emails sent.
If a user owns multiple inactive sites – he/she will get multiple emails.
You can scope the policy down by site template, sensitivity label and creation source if you want different behavior for different types of sites, e.g. if you want to setup longer period of inactivity for one type of sites and shorter for others… not sure when it makes sense…
Implementing an Inactive sites policy
First of all – It is highly recommended to take care of ownerless sites (find owners) before triggering an Inactive sites policy.
If you have a relatively new tenant – you probably have not much inactive sites, so turning the policy on should not be a problem. The older your tenant is the more inactive sites you have. For older tenants you probably already have a lot of inactive sites – ant that could be a problem. So we’d need to take care of initial policy implementation, and after some time it will just work so we could forget about it.
There is no way to pilot this policy with pre-selected scope of sites or users. You can scope the policy down by site template, sensitivity label and creation source, but you cannot scope the policy down the way only sites or uses you want to be a testers or pilot project members will be the target of the policy.
In small orgs there should be no problems implementing this policy. Still I would start from just getting a report. There is a “How long after the last activity should a site be considered inactive?” configuration, so I’d start from the longest – 6 months, then move to the shortest you need. Medium orgs could get some ideas from recommendations to large orgs below.
In large orgs you might
- trigger a spike in number of tickets submitted by users who needs help
- hit a maximum sending limit with Exchange Online which is 10,000 email recipients per day
So it would be crucial for enterprises to avoid an initial surge and start from smaller number of recipients, and gradually let the policy work at a full strength. One of the options to achieve that would be
- configure the policy for reports only, get inactive sites report
- select sites owner and admins in a separate list – then select only unique ones – so every user will get only one email, split this list into small chunks
- communicate to site owners (by chunks) – using enterprise-approved “send from” email and enterprise-branded email template saying that the policy is gonna be implemented, you might receive an email (like this one – screenshot), you can trust this email and click buttons. A list of site urls user owns must be included in the email, so user could visit these sites
(Optionally) you can instruct users how they can delete sites if site is no longer needed or archive sites if they are not sure if it is still needed or not
If so – it’d
- forewarn users so they would know to do and not be surprised and would create less tickets
- users might choose to delete or archive sites which would also
- users would visit their inactive sites and trigger sites activity, and that should dramatically decrease number of emails sent to users initially, on the day one of policy implementation
ideally – if users visit all sites – you’d have no inactive sites, so you’d just turn the policy on with no fear
then you’d wait for a couple of weeks, get new report to ensure that you have much less inactive sites – and you’d just enable the inactive sites policy (starting from the longest period – 6 month of inactivity)