Intune adds deployment plans for staged app and policy rollouts (Preview)
Intune can now roll out a Win32 app, Settings catalog profile, or endpoint security policy in timed rings instead of all at once. Useful, but pausing or cancelling doesn't roll anything back, and the payload isn't locked while the rollout runs.
Intune can now stage a Win32 app, Settings catalog profile, or endpoint security policy through rings (pilot, broad, all devices) natively, instead of admins doing it by hand with calendar reminders. Microsoft lists it under Week of September 21, 2026 in What’s new in Microsoft Intune, under Devices > Manage devices > Deployments.
Key Takeaways
- A deployment plan is a reusable ring template. A deployment runs one specific app or policy through those rings
- Public preview: Windows 10+ only — Win32 apps, Enterprise App Catalog apps, Settings catalog profiles, endpoint security policies
- Ring assignments are cumulative. Cancelling or pausing stops progression but doesn’t remove what already-activated rings added
- The payload isn’t locked: edit it mid-rollout and devices in rings already activated get the change on their next check-in
- Multi Admin Approval, if configured for the payload type, gates create/resume/cancel/delete — not pause
What’s actually supported today
| Payload | Intent | Staging a new version |
|---|---|---|
| Win32 apps | Required only | Supersedence — new app, own deployment |
| Enterprise App Catalog apps | Required only | Update with supersedence (not Automatically update); needs separate Enterprise App Management license |
| Settings catalog profiles | — | No supersedence — manual cleanup of the old policy, ring by ring |
| Endpoint security policies | — | Same — no supersedence, manual cleanup |
Microsoft states directly that cancelling “doesn’t remove assignments that completed rings added to the payload” — pausing works the same way. A deployment edits your real assignments ring by ring; it doesn’t run alongside them. The final All devices/All users ring replaces all prior Required-include assignments on the payload.
Two things cause a rollout to stall: a group assigned both directly on the payload and inside a ring (flagged at creation, by group identity not membership — if missed, the deployment errors out when that ring activates and needs the direct assignment removed before Resume), and a soft- or hard-deleted group in an upcoming ring (cloud groups restorable within 30 days, on-prem-synced groups have no restore window; a permanently deleted group means cancel and rebuild).
Before your first rollout
- Remove pilot/broad groups from the payload’s direct assignments if they’re going into rings
- Write down that pause/cancel ≠ rollback — decide who removes already-added assignments and from where
- Freeze the payload during a rollout, or stage updates via supersedence (Win32/catalog apps) / a manual-cleanup new policy (Settings catalog, endpoint security)
- Build one or two ring plans for the whole team, not one per deployment
Frequently asked questions
Does cancelling a deployment uninstall the app or remove the policy? No. It stops future rings; assignments already added stay on the payload. Remove them there yourself.
Does this need extra licensing? Not for deployments themselves. Enterprise App Catalog apps still need the separate Enterprise App Management subscription, unrelated to this feature.