Intune deployments (preview): stage Win32 apps and policies across deployment rings

Until now, a staged rollout in Intune meant creating pilot groups, assigning the app or policy to them, waiting, then editing the assignment again and again until everyone had it. The new Deployments experience, in public preview since September 2026, turns that routine into a scheduled, ring-based rollout you can pause or cancel. In this post I'll explain how deployment plans and deployments work, what they support today, how to create one, and how they compare with assignment filters and Windows Autopatch groups.

How it works#

The feature lives under Devices › Manage devices › Deployments and has two building blocks:

• Deployment plan: a reusable template that defines rings (each with one or more Microsoft Entra groups and optional assignment filters), the wait time between rings, exclude groups that apply to every ring, scope tags and a platform. A plan contains no payload and can be edited later without affecting deployments already created from it.
• Deployment: the execution of one payload (one app or one policy) through a set of rings, either loaded from a plan or configured manually for a one-off rollout. You set the first ring's start date and time; later rings activate after the configured interval, which must be at least one hour.

Under the hood a deployment edits the payload's own assignments. When a ring activates, Intune adds that ring's groups to the payload's Required include assignments; earlier rings' groups stay, so assignments are cumulative. Microsoft's documentation describes rings progressing on date and time criteria only; I haven't found a documented health gate or per-ring approval step in the preview, so you are the gate: watch the pilot ring and pause if something looks wrong. The payload stays the source of truth, and direct edits to its assignments take precedence over the deployment.

Two special rules matter. A ring that contains the All users or All devices virtual group automatically becomes the final ring, can't be mixed with security groups, and when it activates it replaces the earlier Required include groups (existing exclude assignments are kept). And Intune checks for collisions: a group that is both in the payload's assignments and in a ring must be removed before you create the deployment, and a collision at ring activation puts the deployment into an error state and pauses it until you fix the payload and select Resume.

Prerequisites#

• Supported payloads (public preview): Windows 10 and later only. Policies: settings catalog and endpoint security policies. Apps: Windows app (Win32) and Enterprise App Catalog apps, with the Required intent only; Available and Uninstall aren't supported. For Enterprise App Catalog apps, update with supersedence works, but automatic update isn't supported with deployments.
• Permissions: creating a plan needs Create on the Deployment plan permission category, which the Application Manager, Endpoint Security Manager, Policy and Profile Manager and School Administrator built-in roles have in full; Read Only Operator and Help Desk Operator can only read plans. Deployments have no permission of their own: you need Read and Assign on the payload's category (Device configurations or Mobile apps).
• Scope tags: plans can carry scope tags; deployments can't, so the payload's scope tags decide who sees a deployment and which payloads appear in the picker.
• Multi Admin Approval: if an access policy protects the payload type, creating, resuming, cancelling or deleting a deployment requires approval, and a new deployment doesn't appear in the list until it's approved. The approver needs Read on the payload.
• Groups: each ring needs at least one group, and the payload can't already be in another scheduled or active deployment.

Step-by-step#

1. Create a deployment plan#

1. Go to Devices › Manage devices › Deployments › Deployment plans › Create plan, name it and select Next.
2. Pick a Platform. A specific platform decides which assignment filters you can attach; All platforms keeps the plan generic and you choose filters later, per deployment.
3. Select Add rings, name the first ring (it has no wait time, because the deployment supplies its start), then Add ring for each further ring with a Wait time to next ring in days and hours. Save.
4. Add at least one group to every ring, optionally with filters, add exclude groups (they apply to all rings), add scope tags, review and save.

2. Create a deployment#

1. Go to Devices › Manage devices › Deployments › Create, name it and select Next.
2. On Payload selection, pick Device configuration or App, select Add payload and choose exactly one existing app or policy.
3. On Deployment schedule, either Load deployment plans, set the first ring's start date and time and pick a plan (you can still adjust groups and filters for this run), or Add rings to define a one-time schedule manually.
4. Review and Create. From now on only the name and description are editable; payload, ring names, schedule, groups and scope tags are fixed.

3. Operate it#

Select the deployment to Pause (ring progression stops, assignments already made stay), Resume or Cancel. Cancelling stops future rings but doesn't remove the assignments earlier rings added; remove those from the payload's properties if you need to roll back. You can keep updating the payload itself during a rollout: groups already assigned get the change at their next check-in, and the next ring receives the updated version.

Verify#

• The Deployments list shows each deployment's state and is sorted by when the next ring starts in active deployments (no column sorting yet, and search matches the deployment name only).
• Open the payload after a ring activates: the ring's groups should now appear under its Required assignments.
• Device-level success still lives in the payload's own reporting: the app's Device install status, or the policy's Device and user check-in status and per-setting status. Use those before letting the next ring go.
• If a deployment shows an error, check for a collision or a deleted group. A permanently deleted group shows Group deleted from Microsoft Entra ID and the deployment must be cancelled or deleted; a soft-deleted group can be restored within the 30-day window and the deployment resumed.

How it compares#

A practical ring design#

Build the plan once with device groups rather than user groups, so a policy lands without waiting for a sign-in:

Put kiosks, shared devices and anything that must never get an unreviewed change in a single exclude group; it applies to every ring. Start Ring 0 early in the week so each later ring also lands on a working day, and set wait times in days rather than hours so laptops that were off overnight have time to check in and report before the next ring opens.

Tips & gotchas#

• Because the final virtual-group ring replaces the earlier include groups, a device you later need to keep out has to go into the exclude group, not just out of a ring group.
• Pause is not rollback: devices that already received a Required app keep it. Pair deployments with a tested uninstall or supersedence path.
• Dynamic group membership can lag; a device that joins a ring group after that ring activated still gets the payload, because the assignment now lives on the payload.
• It's a preview: check the known issues page before relying on it for change-controlled rollouts.

References#

• Deployment plans and deployments in Microsoft Intune
• Create and manage a deployment in Microsoft Intune
• Permissions, scope tags, and approvals for deployments