Intune Deployments (Preview): Rollout Rings, Approval Gates and the Assignment Traps
Intune Deployments roll Windows apps and policies out in rings, but pause and cancel only stop progression. What that means for rollback, payload edits and approvals.
Intune Deployments (Preview): Rollout Rings, Approval Gates and the Assignment Traps
Pausing a ring-based rollout in Intune Deployments does not take anything back. Every group that a completed ring added to the app or policy stays assigned, and Microsoft's documentation is explicit about it: canceling a deployment doesn't remove assignments that completed rings added to the payload. If your change-management process treats "Pause" as the rollback button, the process is wrong before the first ring starts.
That single behavior explains most of what an enterprise needs to know about Intune Deployments, the ring-based rollout capability that Microsoft added to the Intune admin center in the week of September 21, 2026 and still documents as public preview. The feature controls when groups get added to a payload, while the payload keeps ownership of its assignments. Every design decision below follows from that.
What actually shipped
The capability has two objects, and keeping them apart prevents most of the confusion.
A deployment plan is a reusable template. It defines rings, the Entra groups and assignment filters in each ring, exclude groups, and the wait time between rings. It carries no payload. A deployment is the execution: one payload, delivered through rings that come either from a plan or from a one-time manual ring configuration. Both live under Devices > Manage devices > Deployments in the Intune admin center.
During the preview, the supported scope is narrow: every payload must target Windows 10 and later.
| Payload category | Supported payloads |
|---|---|
| Device configuration | Settings catalog, Endpoint security policies |
| Apps | Windows app (Win32), Enterprise App Catalog app |
Two app rules matter immediately. Win32 and Enterprise App Catalog apps support only the Required intent; Available and Uninstall are not supported. For Enterprise App Catalog apps, update with supersedence works, but Automatically update isn't supported with deployments. If you already rely on Enterprise App Management auto-updates, read the auto-update security gap analysis before deciding which apps move to ring-based delivery.
The deployments documentation does not list a separate license requirement for the feature. I would still confirm it against your tenant's Intune licensing before you build an operating model around a preview capability.
How assignments change as rings activate
This is the part to understand before you click Create.
When a ring activates, Intune adds that ring's groups to the payload's Required include assignments. The additions are cumulative: ring 2's groups join ring 1's, and any Required assignment the payload already had before the deployment started stays in place. Exclude groups apply to every ring. Microsoft's own assignment walkthrough shows a payload that starts with one existing group, gains two pilot groups, then two broad groups.
The final ring behaves differently when it uses a virtual group. A ring that contains All users or All devices automatically becomes the last ring, it cannot be mixed with Entra security groups, and when it activates, the virtual group replaces the payload's previous Required include assignments. Existing exclude assignments are preserved.
The end state of a deployment that finishes on a virtual-group ring is a payload assigned Required to All devices (or All users) with its excludes. The pilot and broad groups, and any Required group assignment the payload had before the deployment started, are gone from the assignment list. If the target end state should be a set of named groups, do not finish on a virtual ring; make the last ring a group ring instead.
Microsoft states the governing rule in one line: the payload remains the source of truth, and direct changes to payload assignments take precedence over the deployment.
The payload is not locked
A deployment doesn't lock its payload. You can keep editing the app or policy while rings are in flight, and the documented effect is precise: groups already assigned receive the update at their next check-in, and groups in the next scheduled ring receive the updated version.
Read that as a design statement. If someone edits a settings catalog policy on day 3 of a five-day rollout, the edit skips the rings and lands on every device that earlier rings already reached, at its next check-in. The rings only protect the devices that have not been reached yet.
Editing a payload during an active deployment publishes the change to every ring that has already activated, without staging. Treat payload edits during a rollout as a new change: stop, decide whether the edit needs its own staged rollout, and if it does, create a new payload version and a new deployment for it.
My recommendation is a simple process rule: a payload with an active or scheduled deployment is frozen for edits outside an approved change. Intune will not enforce that for you.
Collisions, deleted groups and the error state
Intune checks for an assignment collision, the same group appearing both in the payload's assignments and in a deployment ring, at two moments: when you create the deployment and when each ring activates. At creation, you resolve it before selecting Create. At ring activation, the deployment enters an error state and pauses; you remove the colliding group from the payload's assignments, then Resume.
The activation-time check deserves the most attention, because the payload can change after the deployment was created. Someone adds a group to the app directly, and the next ring that contains the same group stops the rollout.
Deleted groups have their own documented behavior:
| Group state at ring activation | Deployment result | Way out |
|---|---|---|
| Permanently deleted | Error: "Group deleted from Microsoft Entra ID" | Cancel or delete, then create a new deployment |
| Soft-deleted | Error, group shows "Soft-deleted" | Restore within the 30-day window and Resume, or cancel/delete |
| Both soft- and permanently deleted | Error | Cancel or delete |
Resume stays unavailable until every soft-deleted group is restored. Plans that reference deleted groups show a banner and cannot be saved, or used to create a deployment, until the groups are removed or restored.
Collisions also rule out the obvious recovery move. Cancel leaves the completed rings' groups on the payload, so a new deployment that reuses those groups collides with the payload's own assignments, and it cannot be created until you remove those groups from either the payload's assignments or the new deployment's rings.
Approval gates: what Multi Admin Approval covers
Deployments honor Multi Admin Approval (MAA). If an access policy protects the payload type, for example the App Windows platform for a Win32 app, the deployment inherits that approval flow. Per the RBAC and approvals page, four actions trigger approval: Create, Resume, Cancel and Delete. The approver needs Read permission on the payload to open the deployment properties from the request, and a deployment awaiting creation approval does not appear in the Deployments list until it is approved.
Pause is not in that list. My reading is that Pause is the brake one operator can apply alone in an MAA-protected tenant; the documentation does not include it among the MAA-gated actions, but also does not state which permission Pause requires. The documented actions that resume or end the paused deployment, Resume, Cancel, or Delete, do require MAA approval.
Before the first MAA-protected deployment, decide who approves Resume, Cancel and Delete during a rollout window, and how fast. A collision or a deleted group pauses the deployment. Recovery then needs a Resume, or a Cancel or Delete when a group is permanently deleted, and each of those needs a second administrator. If no approver is reachable, the rollout simply waits.
Permissions and scope tags
Deployment plans have their own permission category with Create, Read, Update and Delete. The built-in roles that carry it are listed in the RBAC reference: Application Manager, Endpoint Security Manager, Policy and Profile Manager and School Administrator get full CRUD, while Read Only Operator and Help Desk Operator get Read.
Deployments have no dedicated permission. Creating one requires Read and Assign on the payload's category, Device configurations or Mobile apps; viewing one requires Read on that category.
Scope tags follow the same split. You can tag a plan, but you cannot tag a deployment; the payload's scope tags are the visibility boundary. An administrator sees a deployment only if its payload is in scope, and the payload picker only offers in-scope payloads. If your delegation model already relies on payload scope tags, deployments inherit it without extra design. If it does not, deployments will not fix that.
An illustrative four-ring rollout
Example only. These ring names, groups and timings are a conceptual pattern built from the documented rules, not a tested configuration or a measured outcome.
| Ring | Groups | Starts |
|---|---|---|
| Ring 0, IT validation: catch errors on devices the team can reach | IT devices, filtered to corporate-owned Windows | Day 0, 09:00 |
| Ring 1, early adopters: real workloads, small blast radius | Named early-adopter group | +2 days |
| Ring 2, broad: most of the estate, still group-scoped | Department groups | +3 days |
| Final: replaces the group assignments | All devices (virtual group) | +3 days |
For a first production rollout, replace the Final row with a group ring, as recommended below.
A few documented constraints shape a plan like this. The first ring has no wait time in the plan, because its start date and time are set when the plan is loaded into a deployment. Every later ring needs a wait of at least one hour. Each ring needs at least one group. Exclude groups, for example kiosk or lab devices that should never receive the payload, apply to all rings at once; there is no per-ring exclusion.
When the plan is loaded into a deployment, the groups and assignment filters can still be adjusted for that deployment. After creation, only the deployment's name and description can change: the payload, ring names, schedule, groups and scope tags are fixed. Editing the plan later does not affect deployments already created from it.
Rollback has to be designed outside the deployment
Because pause and cancel only stop progression, reversing a bad change is a payload operation.
For a policy, that means editing the policy itself, or its assignments, and understanding what removing an assignment does for that policy type before you rely on it. For an app, the deployment supports only the Required intent, so any uninstall path has to be built with the app's normal assignments outside the deployment.
If I were writing the runbook for a first production use, I would put three items in it before Ring 0 starts:
- A record of the payload's Required and exclude assignments before the deployment, so you know what "back to the start" means.
- The exact reversal for this payload type: the previous app version and supersedence relationship, or the previous policy settings.
- The named approver for Resume, Cancel and Delete if MAA protects the payload.
There is a trade-off in this. Deployments remove the manual work of adding groups on a schedule, and that is real value. The cost is a second place to look when someone asks why a device has an app: the payload's assignment list shows the result, while the deployment holds the history of how it got there. Change records need to reference both.
Go and no-go checks for a preview feature
Before the first production deployment, these are the checks I would want answered:
- The payload is a supported type: Windows Settings catalog, Endpoint security policy, Win32 app, or Enterprise App Catalog app with Required intent.
- The payload's existing Required assignments are recorded, and none of the ring groups already appear on the payload.
- The payload is not selected in another scheduled or active deployment.
- The final ring is a deliberate choice between named groups and a virtual group, with the replacement behavior understood.
- Every ring group exists and is not soft-deleted.
- Payload edits are frozen for the duration of the rollout.
- MAA approvers for Resume, Cancel and Delete are named and reachable for the rollout window.
- The rollback path is written down and tested on a non-production payload.
The preview also carries known issues worth planning around. The Deployments list cannot be sorted and is ordered by ring start in active deployments. Search matches only the deployment name. An MAA-pending deployment is absent from the list until approval; its status is visible from the deployment itself or from Tenant administration through Multi Admin Approval or Admin tasks. Naming conventions do real work here: if search only matches names, put the payload and change reference in the deployment name.
What Deployments do not solve
Deployments stage the moment a group is assigned. They do not measure success, evaluate install or policy health, or stop on failure rates; the documented controls are time-based progression plus manual pause, resume and cancel. Deciding whether Ring 1 was healthy enough to let Ring 2 start is still an operator's job.
They also do not cover the rest of the endpoint estate yet. macOS, iOS, Android and the other Intune payload types are outside the preview scope, and Windows quality and feature updates already have their own ring model through Windows Autopatch, covered in the Autopatch guide. Assignment sprawl also stays your problem: a deployment adds groups to payloads on a schedule, and the object drift analysis still applies to what is left behind.
My recommendation
Use Deployments now for low-risk Windows payloads where the value is obvious: a Win32 app update with supersedence, or a settings catalog change that can be reversed by editing the policy. Run it with the freeze rule on payload edits and a written rollback, and finish on a group ring until the team has seen the virtual-group replacement happen once in a controlled case.
I would hold off on security-critical Endpoint security policies until your MAA approval path has been exercised under time pressure, because resuming after a recoverable mid-rollout error needs a second administrator. The feature is in preview, and its documented behavior is clear enough to design around today. Most of that design work sits in the payload and its assignments.
