Table of Contents
Planner Tasks Can be Removed or Retained by Retention Policies
Message center notification MC1384412 (last updated 22 June 2026, Microsoft 365 Roadmap item 486828) announces that Data Lifecycle Management retention policies can process Planner tasks. Rollout in general availability is scheduled for mid-July with completion worldwide due by mid-August 2026.
Administrators can create retention policies to retain or delete Planner tasks based on creation date or last modified date. This is noteworthy because although the Planner Graph schema includes properties such as createdDateTime and completedDateTime, it does not expose a last modified date property for tasks. It therefore appears that retention processing relies on information stored in the compliance record rather than task data exposed through Graph APIs.
Retention policies operate against the compliance records generated by the Microsoft 365 substrate for Planner tasks. This approach extends the same substrate-based retention architecture that Microsoft previously introduced for Teams data.
User and Group Plans
Policies can be scoped to user and group-backed plans. A user plan is also called a personal plan. A Loop task list based on Planner is an example of a user plan. A group-backed plan is a plan attached as a resource to a Microsoft 365 group.
Originally, Planner supported a single plan per Microsoft 365 group. Now, a group can support multiple plans, such as in the case where Teams creates plans for use as channel tabs.
Figuring out the Effect of Retention on Tasks
Because rollout has not yet begun, it is difficult to assess the practical impact that retention policies will have on Planner tasks. I decided to use PowerShell and the Microsoft Graph to calculate how many tasks in group-backed plans would be removed by retention policies.
The Graph APIs for Planner are reasonably easy to work with, and I’ve developed several solutions based on plans, like generating a weekly incomplete task report. Some limitations remain. For example, the tasks endpoint currently ignores filter parameters and returns the complete task set regardless of the filter supplied. The solution is easy (use client-side filtering), but annoying.
The script does the following:
- Connects to the Microsoft Graph with Connect-MgGraph. You should use app-only authentication for this script because it requires access to group data and tasks throughout the tenant. This script is a good example of where you might assume that the Group.Read.All permission is needed. In fact, GroupMember.Read.All is sufficient.
- In addition, if you want the script to email the output report, it needs the Mail.Send permission, which should be restricted by RBAC for Applications.
- Defines a retention period. By default, this is 7 years, but you can set it to whatever value you like.
- Finds the set of Microsoft 365 groups in the tenant.
- Checks each group for plans with Get-MgGroupPlannerPlan.
- Retrieves the tasks for each plan with Get-MgPlannerPlanTask and checks for tasks that would be removed because they are past the retention period.
- Report the results and output a report file in either CSV or Excel format. Figure 1 shows an example of the Excel output.
- Emails the report file to a designated recipient (which could be any addressable recipient).
One immediate benefit of analysing Planner data in this way is visibility into obsolete plans scattered throughout the organization. In many tenants, plans are created for evaluation or short-term projects and then forgotten. The date of the last completed task is often a useful indicator of whether a plan remains active. As retention processing for Planner tasks rolls out, understanding which plans are active and which have effectively been abandoned may help tenants refine their retention policies.
The script can be downloaded from the Microsoft 365 for IT Pros GitHub repository. It’s PowerShell, so feel free to alter the code to meet your requirements.
Planner is a Compliance Laggard
Given that Planner has been around since 2016, it is somewhat surprising that Microsoft has taken so long to deliver retention support for Planner. That said, Microsoft’s priorities for Data Lifecycle Management are clearly Exchange Online, SharePoint Online, and Teams. These workloads generate most organizational content and therefore demand the greatest focus for compliance. Even if the wait has been frustrating for Planner enthusiasts, Microsoft’s priorities are probably reasonable.
Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.