Picture the litigation hold email landing in your inbox. Legal wants to know what Microsoft 365 Copilot “knew” about a departing employee three months ago — the inferred preferences, the project associations, the saved facts that shaped every answer Copilot gave them. You go looking. And there’s nothing to find, because Copilot memory is a living document that overwrites itself as it learns. The version that mattered is gone.

That gap is what Microsoft is closing. Roadmap item 569612 — “Data Lifecycle Management: Retention for Copilot Memory” — reaches general availability in September 2026, and it turns Copilot’s memory from an ephemeral personalization cache into something you can retain, version, and produce in an investigation. If you’ve rolled out Copilot at any scale, this is not optional housekeeping. It’s a new data class that just became discoverable.

What Copilot memory actually is, and where it hides

Copilot memory is the feature that makes Copilot feel less like a goldfish. It has two flavors. There are saved memories — things a user explicitly tells Copilot to remember (“I’m the PMO lead for the Helsinki migration,” “always summarize in bullet points”). And there are inferred details — facts Copilot derives from a user’s chat history to personalize future responses. Together they let Copilot stop asking the same context questions on every prompt.

Here’s the part that matters for compliance: those memory items don’t live in some opaque AI service. They’re stored as items in a hidden folder in the user’s Exchange Online mailbox — the same substrate model Microsoft already uses for Teams messages and Copilot interaction history. That’s deliberate, and it’s good news, because anything in the mailbox substrate is reachable by Purview’s retention and eDiscovery machinery.

Until now, though, memory has been managed entirely by the Copilot experience. Active memory changes as the model learns, and the previous state simply disappears. The GA feature adds retention and versioning for inactive memory items: when a memory item is superseded or removed, a retained copy is preserved according to your policy, while active memory keeps being managed by Copilot itself. You get the audit trail without freezing the feature.

Why this surfaces now

Memory shipped as a personalization win. Nobody in the Copilot product team was thinking about the poor eDiscovery admin who’d eventually have to explain, under oath, why an AI made a decision. Regulated tenants — financial services, healthcare, legal, public sector — flagged the obvious problem: if Copilot’s behavior is shaped by stored data about a person, that stored data is discoverable, and “we don’t keep it” is not a defensible answer to a regulator. Retention for memory is Microsoft catching the governance story up to a feature it already shipped.

My read: the interesting word in the feature description is inactive. You are retaining the tombstones, not snapshotting live memory on a schedule. That’s fine for “prove what changed,” weaker for “reconstruct exactly what Copilot believed at 2pm on a Tuesday.” Set expectations with legal accordingly.

The bigger picture: this is one piece of Purview’s Copilot governance stack

Don’t treat memory retention in isolation. It slots into a set of Purview capabilities for Copilot that have landed over the past year, and if you’re planning, plan for all of them together:

• Retention for Copilot interactions (prompts and responses) — already GA, configured as its own location in retention policies. Memory retention is the companion piece.
• eDiscovery (Premium) for Copilot — Copilot interactions are collectable; memory items become collectable content under the same model once retained.
• Communication Compliance for Copilot — policy scanning of prompts and responses for risky content.
• DSPM for AI (Data Security Posture Management for AI, in the Purview portal) — the dashboard that shows you which users are using Copilot, what sensitive data they’re touching, and where your governance gaps are. This is where you should start your Copilot data-risk conversation.
• Purview Audit for Copilot — interaction events flow to the unified audit log.

The practical benefit versus the old world is straightforward. Before, Copilot memory was a black box you couldn’t retain, search, or defend. After, it’s a governed data class with a retention timeline you set, a version history for “what changed,” and a production path into eDiscovery. You’re trading an unbounded liability for a bounded, documented one. That’s the whole game in compliance.

Find out who’s exposed before you write a single policy

Scope first. Only Copilot-licensed users generate memory, so start by inventorying who actually has the license. This uses the Microsoft.Graph module — install with Install-Module Microsoft.Graph -Scope CurrentUser if you haven’t.

Connect-MgGraph -Scopes "User.Read.All","Organization.Read.All"

try {
    # Copilot SKU part number; confirm against your tenant's Get-MgSubscribedSku output
    $copilotSku = Get-MgSubscribedSku -All |
        Where-Object { $_.SkuPartNumber -eq 'Microsoft_365_Copilot' }

    if (-not $copilotSku) { throw "No Microsoft 365 Copilot SKU found in this tenant." }

    # -All handles paging automatically; do NOT roll your own $top loop here
    $licensedUsers = Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AssignedLicenses |
        Where-Object { $_.AssignedLicenses.SkuId -contains $copilotSku.SkuId }

    $licensedUsers |
        Select-Object DisplayName, UserPrincipalName, Id |
        Sort-Object DisplayName |
        Export-Csv .\Copilot-Licensed-Users.csv -NoTypeInformation

    Write-Host "$($licensedUsers.Count) Copilot-licensed users exported." -ForegroundColor Green
}
catch {
    Write-Warning "License inventory failed: $($_.Exception.Message)"
}
finally {
    Disconnect-MgGraph | Out-Null
}

That CSV is your review set. Everyone on it is generating memory items right now, retained by nothing.

Now check what retention already exists. Retention compliance policies still live in Security & Compliance PowerShell — Graph doesn’t fully cover retention policy objects yet, so this is the correct modern module for the job (it ships in ExchangeOnlineManagement, not the retired MSOnline/AzureAD modules).

Connect-IPPSSession -UserPrincipalName [email protected]

try {
    Get-RetentionCompliancePolicy -DistributionDetail |
        Select-Object Name, Enabled, Mode,
            @{N='Locations';E={ ($_.ExchangeLocation.Name) -join '; ' }} |
        Format-Table -AutoSize

    # Rules carry the retention duration and action
    Get-RetentionComplianceRule |
        Select-Object Name, Policy, RetentionDuration, RetentionComplianceAction |
        Format-Table -AutoSize
}
catch {
    Write-Warning "Could not enumerate retention policies: $($_.Exception.Message)"
}

Building the policy — dry-run first, always

The retention location for Copilot memory surfaces in the Purview portal as a Copilot workload alongside interactions. In PowerShell, the exact location parameter for the memory scope is being finalized as the feature reaches GA, so confirm the parameter name in your tenant against the current cmdlet help before you run this for real. What must not change is the discipline: never point a creation cmdlet at the output of a live query and let it rip.

# SAFE BY DEFAULT: -WhatIf shows what would happen and changes nothing.
# Remove -WhatIf only after you have reviewed the plan and the scope CSV.

$policyName = "Copilot Memory Retention - 7yr"

try {
    New-RetentionCompliancePolicy `
        -Name $policyName `
        -Comment "Retains inactive Copilot memory items for investigation/compliance." `
        -ExchangeLocation "All" `
        -WhatIf

    New-RetentionComplianceRule `
        -Name "$policyName-Rule" `
        -Policy $policyName `
        -RetentionDuration 2555 `      # ~7 years, in days
        -RetentionComplianceAction Keep `
        -WhatIf
}
catch {
    Write-Warning "Policy planning failed: $($_.Exception.Message)"
}

Scope tightly. -ExchangeLocation "All" is a blunt instrument; for a phased rollout, target a reviewed group or an explicit list of the mailboxes from your CSV rather than the entire tenant. And decide Keep versus KeepAndDelete deliberately — retaining memory tombstones forever is its own liability. Match the duration to your existing records schedule, not to a round number that felt safe.

Where this lives in the portal

Everything configures in the Microsoft Purview portal (purview.microsoft.com) under Data Lifecycle Management → Policies → Retention policies. Create or edit a policy and you’ll pick the Copilot workload as a location; the memory scope appears there as it rolls out. For the risk picture that should drive your scoping decisions, go to DSPM for AI in the same portal first — it tells you who’s actually using Copilot and against what data.

What will bite you in six months

Two things. First, retention makes memory discoverable, which cuts both ways: you’re preserving evidence you’ll be obligated to produce. If legal hasn’t blessed a duration, don’t set one long by reflex. Second, memory retention interacts with mailbox lifecycle. When a user leaves and their mailbox becomes inactive, retained memory items ride along under the same rules as the rest of the substrate — so your leaver process and your Copilot retention policy need to agree on how long that data lives, or you’ll discover a five-year cache of AI-inferred details about ex-employees nobody signed off on.

Do this before September

1. Run the license inventory above. Know your exposed population.
2. Open DSPM for AI and read the Copilot usage/risk report. That’s your scoping input.
3. Get legal to commit to a retention duration for memory — align it to your existing records schedule.
4. Build the policy in -WhatIf, scoped to a pilot group, and verify against your reviewed CSV before you go tenant-wide.

Copilot memory is a genuinely useful feature and a quiet new liability at the same time. September is when you get the controls. Have the policy drafted before then, not after the first eDiscovery request lands.

Here’s the part the roadmap card doesn’t say out loud: the Capacity view landing in Planner in October 2026 is a paid feature. It looks like a natural extension of the boards your teams already use for free, sitting one tab over from Grid and Board. But the moment someone clicks it and sees “upgrade to unlock,” you’ll get the ticket. And then you’ll get the second ticket, from a manager who tried it on a trial and now wants it for all 40 people in the department.

So let’s get ahead of it. This is a genuinely useful feature — resource-levelling has been missing from basic Planner since day one — but it carries a licensing cost that admins need to model now, not scramble for when a director asks why their team can’t see it.

What Capacity view actually does

Capacity view (roadmap item 569733, GA October CY2026) puts every assignment on a timeline against the people doing the work. Instead of squinting at a board and mentally tallying how many cards each person is holding, you get a horizontal view: rows for people, bars for their assigned tasks over time. Someone stacked three deep in the same week shows up as an obvious block. Someone with a clear fortnight shows up as white space you can fill.

If that sounds familiar, it should. This is resource management lifted out of Project for the web and dropped into the Planner app in Teams. The concept isn’t new — Project has done capacity and resource engagement for years. What’s new is that Microsoft is surfacing it inside the Planner experience most of your users already live in, which massively widens the audience that will want it.

The productivity gain is real and easy to articulate to a budget holder. Before Capacity view, load-balancing across a team was a manual, gut-feel exercise done in someone’s head or a spreadsheet. After it, an overloaded engineer or a stalled sprint is visible at a glance, before the missed deadline rather than after. That’s the pitch. It’s also the trap, because the pitch works so well that demand outstrips whatever you’ve licensed.

The licensing catch nobody’s flagging

Basic Planner — the free experience that ships with Microsoft 365 and every Microsoft 365 Group — does not include premium plans, and Capacity view is a premium plan feature. To use it, a user needs a premium Planner license. These are the plans Microsoft rebranded from Project in 2025:

• Planner Plan 1 (formerly Project Plan 1) — the entry point for premium plans, sprints, goals, and the timeline/schedule views that Capacity view belongs to.
• Planner Plan 3 (formerly Project Plan 3) — adds the desktop Project client and roadmap-level capabilities.
• Planner and Project Plan 5 (formerly Project Plan 5) — portfolio, demand management, enterprise resource capacity.

Here’s what bites you in six months: the person who creates the premium plan needs the license, and depending on how your teams collaborate, contributors interacting with premium features may need one too. Microsoft’s own guidance on premium plan access has shifted more than once, so don’t assume “one licensed owner covers the whole team.” Model it per-user and validate against your actual usage. The renaming from Project to Planner also means your existing Project licenses are the Planner premium licenses — check what you already own before you buy anything.

Audit what you can actually turn on today

You have fourteen months. Use the first hour of it to find out where you stand: how many premium seats you own, how many are consumed, and who’s already sitting on a Project/Planner license they’ve forgotten about. Everything below uses the modern Microsoft.Graph module — no AzureAD or MSOnline, both of which are on their way out.

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All","Tasks.Read.All","Organization.Read.All"

# Premium Planner SKUs are the rebranded Project SKUs.
# Verify the exact part numbers in YOUR tenant with Get-MgSubscribedSku first —
# these vary by agreement type (EDU/GCC/commercial).
$plannerSkuParts = @("PROJECT_P1","PROJECTPROFESSIONAL","PROJECTPREMIUM")

$skus = Get-MgSubscribedSku -All |
    Where-Object { $plannerSkuParts -contains $_.SkuPartNumber }

if (-not $skus) {
    Write-Warning "No premium Planner/Project SKUs found. Confirm part numbers with: Get-MgSubscribedSku -All | Select SkuPartNumber, SkuId"
}

$skus | Select-Object SkuPartNumber,
    @{n='Enabled';   e={$_.PrepaidUnits.Enabled}},
    ConsumedUnits,
    @{n='Available'; e={$_.PrepaidUnits.Enabled - $_.ConsumedUnits}} |
    Format-Table -AutoSize

That tells you the seat pool. Now find the humans holding those seats, so you know who can use Capacity view on day one and who’ll be raising a ticket:

$targetSkuIds = $skus.SkuId

# Get-MgUser -All handles pagination automatically — no manual @odata.nextLink loop needed.
$licensedUsers = Get-MgUser -All `
    -Property Id,DisplayName,UserPrincipalName,AssignedLicenses,AccountEnabled |
    Where-Object {
        ($_.AssignedLicenses.SkuId | Where-Object { $targetSkuIds -contains $_ }).Count -gt 0
    }

$licensedUsers |
    Select-Object DisplayName, UserPrincipalName, AccountEnabled |
    Sort-Object DisplayName |
    Export-Csv .\planner-premium-licensed-users.csv -NoTypeInformation

Write-Host "$($licensedUsers.Count) users hold a premium Planner license."

Watch for disabled accounts still holding a premium seat — that’s reclaimable budget sitting idle, and reclaiming it before renewal is the cheapest win in this whole exercise.

It’s also worth inventorying the plans themselves, so you know which teams are heavy Planner users and therefore the most likely to demand Capacity view. There’s no single “get all plans” endpoint, so you enumerate through the groups that own them:

$groups = Get-MgGroup -All `
    -Filter "groupTypes/any(c:c eq 'Unified')" `
    -Property Id,DisplayName

$planInventory = foreach ($g in $groups) {
    try {
        Get-MgGroupPlannerPlan -GroupId $g.Id -All -ErrorAction Stop |
            Select-Object @{n='Group';   e={$g.DisplayName}},
                          @{n='PlanTitle';e={$_.Title}},
                          @{n='PlanId';   e={$_.Id}},
                          @{n='Created';  e={$_.CreatedDateTime}}
    }
    catch {
        Write-Warning "Plan lookup failed for '$($g.DisplayName)': $($_.Exception.Message)"
    }
}

$planInventory | Sort-Object Group | Export-Csv .\planner-plan-inventory.csv -NoTypeInformation

On a large tenant this loop is slow and will occasionally throw throttling (HTTP 429). The try/catch keeps one bad group from killing the run; for tenants with thousands of groups, add a short Start-Sleep between iterations or batch it.

Assigning the seats — on reviewed input only

When the requests come in, resist the urge to pipe a live query straight into a license assignment. Assign from a CSV you’ve actually reviewed with the budget owner. This script defaults to a dry run — it prints what it would do and changes nothing until you explicitly pass -Apply, and it only ever touches the rows in your reviewed file:

param(
    [string]$InputCsv      = ".\reviewed-capacity-users.csv",  # must contain a UserPrincipalName column
    [string]$SkuPartNumber = "PROJECT_P1",
    [switch]$Apply   # omit this and the script only reports. Nothing changes without -Apply.
)

$sku = Get-MgSubscribedSku -All | Where-Object SkuPartNumber -eq $SkuPartNumber
if (-not $sku) { throw "SKU $SkuPartNumber not found in tenant." }

$available = $sku.PrepaidUnits.Enabled - $sku.ConsumedUnits
$requested = (Import-Csv $InputCsv).Count
if ($requested -gt $available) {
    Write-Warning "Requesting $requested seats but only $available available. Buy more before applying."
}

Import-Csv $InputCsv | ForEach-Object {
    $upn = $_.UserPrincipalName
    if ($Apply) {
        Set-MgUserLicense -UserId $upn -AddLicenses @{SkuId = $sku.SkuId} -RemoveLicenses @()
        Write-Host "ASSIGNED $SkuPartNumber -> $upn"
    }
    else {
        Write-Host "[DRY RUN] would assign $SkuPartNumber -> $upn"
    }
}

Run it once with no switch, eyeball the output, confirm the seat math, then re-run with -Apply. The same rule applies to any reclamation script you write against those disabled accounts — review, then apply.

Where this lives in the admin center

Planner has no dedicated admin portal, which surprises people every time. Your controls are spread across a few places:

• Licensing and seat counts: Microsoft 365 admin center → Billing → Licenses, and Billing → Purchase services for buying more premium Planner seats.
• App availability and pinning: Teams admin center → Teams apps → Manage apps and Setup policies — this is where you pin the Planner app so users find it, and where you’d block it if you needed to.
• Tenant-level Planner settings: still Graph/PowerShell territory (iCal publishing, roster creation) — there’s no GUI for most of it.

The bigger Planner picture you should be planning for

Capacity view doesn’t arrive in isolation. The Planner app in Teams is now the consolidated home for To Do, Planner, and Project for the web — the old “Tasks by Planner and To Do” name is gone. If your setup policies still reference the old app name, fix that before your users go looking for the new features.

Two other threads matter for the same admin workflow. First, Copilot in Planner — plan generation, goal breakdown, and task drafting — is itself a premium capability layered on top of both a premium Planner plan and a Copilot license. If you’re modelling budget for Capacity view, model Copilot in the same conversation, because the same power users will want both. Second, premium plan features like sprints and goals ride the exact same license as Capacity view. In other words, one Plan 1 seat unlocks the whole premium tier, so frame the purchase as “premium Planner for this team,” not “the timeline thing one manager asked for.” That reframing usually makes the business case easier, not harder.

My take

Capacity view is a good feature landing in the right place. Resource levelling belongs where the work already happens, and Teams is where it happens. The feature isn’t overrated — the surprise is.

Prioritise like this. Now: run the audit, find idle premium seats on disabled accounts, and reclaim them. Before Q3 2026: identify your two or three heaviest Planner teams and cost out premium seats for them specifically — those are your first adopters and your best pilot. When it goes GA in October: turn it on for the pilot from a reviewed CSV, not a bulk assignment, and let the results build your case for a wider rollout. Do it in that order and Capacity view becomes a planned upgrade with a clear ROI story. Ignore it and it becomes a support queue full of “why can’t I see the timeline” the week it ships.