Operations
From the field archive · Learned in 2024
There's No "Archive" Button: Retiring Power Platform Apps and Flows
A customer asked me how to archive old apps and flows. The honest answer was that the button doesn't exist. Here's the process I recommended instead, updated for today's tools.
In the fall of 2024 a customer's platform team asked me a question that sounded simple: how do we archive apps, flows, and reports we no longer use? They didn't want to delete anything outright. They wanted to move it out of the way, keep a copy, and be able to bring it back if someone complained. This is a common point of confusion, because "archive" is a word people expect to find in every admin console.
My answer then was direct. Power Platform doesn't have an archive option for apps and flows. What it does have is a set of building blocks: tools to find inactive resources, ways to turn them off, ways to export them, and short recovery windows after deletion. Put together with a bit of process, those blocks give you something that works like an archive. That's still true today, but the building blocks are better.
In 2024 I pointed customers to the CoE Starter Kit to find inactive resources. The kit is now no longer actively maintained; Microsoft points to the Power Platform admin center instead. Inventory gives a tenant-wide list of apps, flows, and agents with owners. Managed Environments usage insights send a weekly digest that lists apps and flows that haven't been launched in a while. Deleted cloud flows can be restored for 21 days, and admins can recover deleted canvas apps with PowerShell. There's still no archive button. The right approach is still a documented retirement process.
01Why "archive" is the wrong mental model
When people say archive, they usually mean three different things at once: stop it from running, stop people from using it, and keep a copy just in case. In Power Platform those are separate actions, and they work differently for apps, flows, and agents. Once you separate them, the problem gets much easier.
| What you want | Cloud flows | Canvas apps |
|---|---|---|
| Stop it running | Turn the flow off | Not applicable; apps only run when launched |
| Stop people using it | Remove run-only users and co-owners | Unshare it, or quarantine it so users see a message instead of the app |
| Keep a copy | Export the solution, or export the flow package if it isn't in a solution | Export the solution, or export the app package |
| Remove it | Delete; restorable for 21 days | Delete; admins can recover it with PowerShell for a limited time |
App quarantine is worth knowing about. Microsoft documents a PowerShell cmdlet that sets a canvas app to a quarantined state, which makes it unavailable to users without deleting it. It's the closest thing to a "soft archive" for apps.
02Find what's inactive
You can't retire what you can't see. In 2024 the answer was the CoE Starter Kit's inactivity flows. Interestingly, those flows used to be called "archive" flows, and Microsoft renamed them to "inactivity notifications" because they never actually archived anything. They asked makers whether to keep or remove their resources.
Today I'd use the admin center first:
Inventory
One list of apps, flows, and agents across the tenant, with owners. Filter by environment and owner, and export a snapshot to Excel.
Usage insights
A weekly email digest. One section lists apps and flows that haven't been launched in a while, with a last-launch date. Tenant-level analytics must be on.
Actions
Recommendations you can act on, such as assigning an owner to an ownerless app. Full detail needs Managed Environments.
I cover each of these in more depth in my governance tools guide.
Don't treat "not launched in 90 days" as "safe to delete." Some of the most important automations run once a quarter or once a year. Always check with the owner, and look at the business calendar before you act.
03The platform may retire things for you
Before you build a process, know which retirement rules are already built in. They surprise people.
- Inactive cloud flows. Microsoft documents that a cloud flow that isn't triggered within 90 days might be turned off. Flows owned by users with premium licenses, or with capacity licenses, aren't subject to this rule.
- Failing flows. A cloud flow whose trigger or actions fail continuously for 14 days is turned off.
- Inactive environments. Automated processes identify, disable, and eventually delete inactive environments in some cases, such as developer environments. Admins and environment creators get email warnings first.
Microsoft Learn also notes that unmanaged developer environments are scheduled to be suspended starting in December 2026, separate from the inactivity schedule. If your makers use developer environments, check the current dates and guidance on Learn now.
These rules can do part of your cleanup, but they can also turn off something important without the right person noticing. Make sure every business-critical flow has a co-owner or a service principal owner, so warnings go to someone who still works there.
04The retirement runbook I recommend
This is the process I suggested in 2024, refreshed with today's tools. It's deliberately boring. Boring is what you want when you're removing things people might depend on.
Identify
- Pull candidates from Inventory and the weekly digest
- Confirm the owner, or find the manager if the owner has left
- Note the connectors used and any downstream dependencies
Notify and pause
- Tell the owner and users the planned date
- Turn flows off; quarantine or unshare apps
- Wait one full business cycle, usually 30 to 90 days
Export and remove
- Export the solution or package
- Store it with its metadata in a governed location
- Delete, then log what you removed and where the copy lives
When the customer asked about archiving, I explained there was no archive option and suggested a workaround: use the CoE Starter Kit to identify inactive apps and flows, confirm with the makers, export what they wanted to keep, and then remove the rest. Looking back, the piece I'd stress more today isn't technical. Agree up front who can approve a deletion, so the platform team isn't making business decisions on its own.
05Exporting: what to keep and where
An export is only useful if someone can restore it later and understand what it was. Here's what I recommend storing for each retired item:
| Item | Why it matters |
|---|---|
| The exported file | A solution export, or an app or flow package for items outside solutions |
| Owner and approver | Who agreed it could be retired, and who to ask about restoring it |
| Connectors and connections | Connections aren't part of the export. You'll need to recreate them on import |
| Environment and dependencies | Tables, environment variables, and child flows the item relied on |
| Retirement date and reason | So a future reviewer knows whether it's safe to remove the export too |
Solutions make all of this easier. If you're still finding important flows outside solutions, that's a good reason to move them in. Microsoft documents that you can't change the owner of a non-solution cloud flow in place, which is one more limitation that goes away once a flow lives in a solution.
Store exports somewhere with its own retention policy, such as a SharePoint library governed by Microsoft Purview retention. Then your archive has a lifecycle too, and doesn't become the next thing nobody owns.
06Recovery windows you should know
Deletion isn't always final right away, but the windows are short. Know them before you rely on them.
| Resource | Recovery option | What to know |
|---|---|---|
| Cloud flows | Restore within 21 days | Use PowerShell or the Power Automate Management connector. Restored flows come back turned off |
| Canvas apps | Admin recovery with PowerShell | Permissions must be re-created after recovery. Check current docs for the recovery window |
| Environments | Recover from the admin center | The standard soft-delete period is seven days, with exceptions for some production environments |
None of these replace an export. They're a safety net for mistakes, not a retention strategy.
The same thinking applies to agents. As agent counts grow, retiring an agent cleanly, including its knowledge sources, connections, and sharing, is becoming part of the same process. I cover ownership and handover for agents in Agent Ownership When Makers Leave.
Where I'd start
Stop looking for an archive button and write a one-page retirement runbook instead. Turn on tenant-level analytics and the weekly digest, use Inventory to find candidates, and agree who can approve a deletion. Pause before you delete, export what you keep with its metadata, and know your recovery windows. It's a small amount of process, and it keeps your tenant tidy without anyone losing something they needed.
Happy to go deeper on any of this.
— K.G
Sources
- Microsoft Learn: Usage insights (Managed Environments weekly digest)
- Microsoft Learn: Set up inactivity notifications components (CoE Starter Kit); Set up app quarantine components
- Microsoft Learn: Set-AppAsQuarantined; Get-AdminRecoverDeletedPowerApp (Microsoft.PowerApps.Administration.PowerShell)
- Microsoft Learn: Restore deleted flows in Power Automate
- Microsoft Learn: Limits of automated, scheduled, and instant flows (retention limits)
- Microsoft Learn: Automatic deletion of Power Platform environments; Recover a recently deleted environment
- Microsoft Learn: Change the owner of a cloud flow
Get new posts by email
Provider: your email provider
