Microsoft Planner: Setup, Policies, and Admin Configuration Guide 2026

Assuming you've confirmed you're on a qualifying subscription, the next step is verifying that the Planner service isn't administratively disabled for your tenant. Microsoft 365 gives admins the ability to turn individual services on or off at the tenant level, and Planner is one of those toggleable services.

To check and change this, go to admin.microsoft.com. In the left navigation, click Settings > Org settings. Scroll through the list until you find Planner. If you don't see it immediately, use the search box at the top of the Org settings page and type "Planner."

Inside the Planner settings panel, you'll see an option that reads something like Allow users to create plans in Microsoft Planner. Make sure this is enabled. If your organization had previously disabled Planner before the April 2024 unification, say, because you were exclusively using Project for the web, it may still be set to off for the new unified experience.

Once you save the setting, users should see the Planner app available in the Teams app bar and at planner.cloud.microsoft. If users still don't see it in Teams, they may need to manually add it: in Teams, click the Apps button in the left sidebar, search "Planner," and click Add. As an admin, you can also pin Planner to the Teams left rail for all users via a Teams app setup policy in the Teams admin center.

One thing to keep in mind: turning Planner on at the org level doesn't automatically pin it for every user. The toggle is more of a "allow access" gate. The pinning and visibility experience for the app in Teams is managed separately through Teams app policies, which I'll cover in Step 3.

If the setting was already on and users still can't access Planner, move on to the next step, this is almost always a license assignment issue rather than a tenant setting problem.

Once the tenant-level Planner service is active, you need the right licenses in place for each user tier you want to support. Here's where many admins hit their second wall: there are now effectively two tiers of Planner, and they require different licenses.

Basic Planner (included in standard Microsoft 365 plans): Users get four views, Grid, Board, Schedule, and Charts, plus My Tasks and My Day. This covers most task and team collaboration scenarios for everyday users.

Premium Planner (requires an additional license): Users get access to Timeline (Gantt) view, Goals, task dependencies, sprints, custom fields, team workload management, and report creation. This requires a Project Plan 1 license at minimum (now officially branded Planner Plan 1). For the full advanced feature set, you need Planner and Project Plan 3 or Planner and Project Plan 5.

To assign these licenses, go to admin.microsoft.com > Billing > Licenses. Find the appropriate plan, click it, then click Assign licenses. You can assign to individual users or to a group via group-based licensing, which is the better approach for anything over 10 users.

For group-based licensing, navigate to Microsoft Entra admin center > Groups, select your target group, click Licenses, and assign the plan there. Every member of the group inherits the license automatically, including new members you add later. This saves a lot of manual re-work as your org grows.

After assignment, verify via PowerShell:

Get-MgUserLicenseDetail -UserId user@contoso.com |
  Select-Object -ExpandProperty ServicePlans |
  Where-Object {$_.ServicePlanName -like "*PLANNER*" -or $_.ServicePlanName -like "*PROJECT*"}

You should see the relevant service plans listed with a ProvisioningStatus of Success. If you see PendingInput, the license is assigned but waiting on something, usually a location setting on the user object.

Microsoft Planner doesn't have its own authentication system. All sign-in flows go through Microsoft Entra ID (formerly Azure Active Directory). This means every Entra-level control you're already using, Conditional Access policies, token lifetime settings, MFA requirements, applies to Planner automatically.

If users are reporting sign-in loops, "you don't have access" errors when opening Planner, or getting bounced back to the login screen repeatedly, the first place to check is your Conditional Access policies in entra.microsoft.com > Protection > Conditional Access > Policies.

Look for any policies that target "All cloud apps" or explicitly list Microsoft Planner. A common misconfiguration is a policy that requires a compliant device or a specific IP range but doesn't have the Planner app excluded from its scope, meaning remote workers or BYOD users get blocked silently. The policy may not throw an obvious error; it just redirects users in a loop.

To troubleshoot a specific user's Entra sign-in experience, go to entra.microsoft.com > Monitoring & health > Sign-in logs. Filter by the user's UPN and look for failed sign-ins with the application name matching Planner or the Office 365 suite. Each entry tells you exactly which Conditional Access policy blocked or interrupted the session and why.

For token lifetime, Planner inherits whatever your Entra token lifetime policies define. If users are being asked to re-authenticate too frequently (a common complaint), check your token lifetime configurations at entra.microsoft.com > Applications > Token configuration or via PowerShell:

Get-AzureADPolicy | Where-Object {$_.Type -eq "TokenLifetimePolicy"}

Adjusting the access token lifetime to 60–90 minutes and the refresh token to 14 days resolves most "keeps logging me out" complaints for Planner users in standard enterprise environments, without meaningfully weakening your security posture.

This is the step most admins skip, and it causes the most downstream confusion. In Microsoft Planner, every plan lives inside a container, and the container controls who can see and edit that plan. Understanding containers is the key to understanding Planner's entire permission model.

Here's what that means in practice. When a user creates a plan inside a Microsoft 365 Group (which is what happens by default when you create a plan from the Planner app), the membership of that Group defines exactly who can view and edit tasks in that plan. Add someone to the Group, they get plan access. Remove them, they lose it. You don't need to manage plan permissions separately, the Group membership is the permission.

Plans can also live inside other container types: a Teams Channel (for channel-based collaboration), or a Meeting (for meeting-specific task tracking). Channel plans inherit their access from the channel membership. Meeting plans inherit from the meeting attendees.

For standard scenarios, the key admin task here is making sure your Microsoft 365 Group policies are properly configured. Navigate to entra.microsoft.com > Groups > General to review your group creation and management policies. If you've restricted Group creation to admins only (a common enterprise setting), users won't be able to create new Planner plans that require a Group. Make sure the right set of users or groups has Group creation rights, or create a designated security group that's allowed to create Groups and add your Planner power users to it.

One advanced customization worth knowing: you can further restrict task create/update/delete permissions within a plan, beyond what the Group membership grants, via the Business Scenarios API. This is mainly relevant if you're building automated workflows or need role-based restrictions inside a single plan (e.g., view-only access for certain members). This is not a standard admin center toggle; it requires Graph API calls, so it's something to hand off to your development team or a power admin.

When the container setup is correct, users in the Group or Channel should be able to open the plan, see all tasks, create new tasks, and edit existing ones without any additional setup. If they can't, re-check their Group membership and whether the plan is actually attached to the container you think it is.

Once access is working, take 20 minutes to lock down the security and compliance configuration. This step often gets deferred and then forgotten, which becomes a problem when your organization faces an audit or a data request.

Here's the data landscape for Microsoft Planner. Basic plan data, task titles, descriptions, metadata, is stored in Azure, encrypted both at rest and in transit. You don't need to configure this; it's on by default. However, it's worth knowing that Customer Managed Keys (CMK) are not supported for basic plan data in Planner as of the current documentation. If CMK is a compliance requirement for your org, this is a constraint you need to flag to your compliance team now, not during an audit.

File attachments in Planner are stored in SharePoint. Conversations associated with plans are stored in Exchange. Both of those are covered by your existing SharePoint and Exchange compliance configurations, eDiscovery, retention policies, DLP rules, so make sure those are in place and tested.

Premium plan data lives in Dataverse. Access to Dataverse for reporting or integration purposes is managed through standard Dataverse role controls, not through the Planner interface. If your organization uses premium Planner plans and you need to give a Power BI reporting team access to the underlying data, they need appropriate Dataverse roles assigned, check admin.powerplatform.microsoft.com > Environments > [Your environment] > Settings > Users + permissions.

For compliance coverage across the organization, Planner is governed under the Microsoft Product Terms and the Data Protection Agreement (DPA). The Microsoft Trust Center is the authoritative source for compliance certifications (SOC 2, ISO 27001, etc.), verify that Planner is listed under the certifications your organization requires.

One quick admin action: make sure your Microsoft Purview configuration covers Planner data. Secondary copies of Planner task data are stored in data management services for Purview integration, so Planner tasks can appear in eDiscovery and compliance search results. Verify this is working by running a test content search in purview.microsoft.com > Content search targeting a known user's Planner tasks.

Finally, there are no special Planner-specific administrative roles. If you ever need to take administrative action on a specific plan, say, to recover a deleted plan or investigate suspicious task changes, you do it by joining the container. For a Group-based plan, that means adding yourself to the Microsoft 365 Group via Entra ID, taking your admin action, then removing yourself. Document this process in your admin runbook so it's not improvised under pressure during an incident.