Posted in

Intune deployment plans arrive in preview: the payload is still yours

by ailona•

Intune deployment plans went into public preview during the week of September 21, 2026. In the Intune admin center they live under Devices > Manage devices > Deployments, and the shape of the feature is easy to describe: a plan is a reusable set of rollout rings with no payload inside it, and a deployment takes one app or one device configuration policy and walks it through those rings on a schedule. For anyone who has been rebuilding the same pilot-then-broad group assignments by hand every month, this removes a manual step that recurs with every rollout. It only pays off if you know which object actually controls the fleet.

A plan is a template, a deployment is a single run

A deployment plan holds the shape of a rollout: the device platform, the rings with their group assignments and assignment filters, exclude groups that apply to all rings, scope tags, and a wait time in days and hours between rings. The one-hour floor on that wait time is documented, and you do not set it on the first ring at all. The first ring’s start date and time are chosen when the plan is loaded into a deployment, because the same plan is meant to be reused.

Plans can be edited afterwards, with a caveat worth remembering: changes do not reach deployments that were already created from that plan. A deployment is the run itself. It carries exactly one payload, it cannot reuse a payload that is already sitting in another scheduled or active deployment, and once you create it you can change the name and description and nothing else. Ring names, groups, schedule and scope tags are frozen. If the shape is wrong, you cancel or delete and build a new deployment.

The part worth reading twice: the payload is still in charge

A deployment does not lock its payload: “the payload remains the source of truth for assignments, and direct changes to payload assignments take precedence over the deployment.” Keep editing the app or the policy while a rollout is in flight and the existing assignments take the change at the next device check-in, while the next ring that activates gets the newer version. Include-group assignments accumulate as each ring goes active. Exclude groups apply to all rings. A ring that uses the All users or All devices virtual group automatically becomes the final ring, and when it activates that virtual group replaces the payload’s earlier required include assignments, with existing excludes left in place.

Pause and cancel stop ring progression, and neither one undoes anything. Assignments from rings that already activated stay on the payload, which gives you a rollout that reaches a third of the fleet and then stops there on purpose.

“Canceling a deployment doesn’t remove assignments that completed rings added to the payload. To remove those assignments, edit the payload’s properties.”

The documented actions on a deployment are pause, resume and cancel, and none of them takes back what a completed ring already did. Undoing a staged rollout means editing the payload’s assignments yourself.

Two failure modes are documented as hard stops. The first is an assignment collision, meaning the same group appears in the payload’s assignment properties and in a ring. Intune checks for it when you create the deployment and again when each ring activates. At creation you remove the group from the payload or from the ring. At activation the deployment goes into an error state and pauses, and you clean up the payload assignment before you resume. The second is a deleted group. A permanently deleted group in an activating ring errors the deployment with “Group deleted from Microsoft Entra ID” and you rebuild. A soft-deleted group errors it too, and resume stays unavailable until every soft-deleted group is restored inside the 30-day recovery window.

Multi Admin Approval gates the deployment too

If an MAA access policy protects the payload type, the deployment inherits the approval flow. Create, resume, cancel and delete all trigger an approval request, so an urgent cancel during a bad rollout can sit waiting on a second admin. Pause is not on that list. Two other details matter in practice. An approver needs Read permission on the payload, or the deployment properties link in the request opens nothing useful. And a deployment created under MAA does not appear in the Deployments list until the approval completes, so an admin who refreshes the list and sees nothing has not been skipped, the rollout is still parked in the approval queue. Intune sends no notification when an MAA request is created or changes status, so route those requests through Teams, mail or whatever the service desk actually watches.

Checks to run before your first staged rollout

  • Pull the payload’s current assignments next to your rings and remove the overlap before you create the deployment. Collisions stop a live rollout, not just a dry run.
  • Check both permission sets. Plan create, read, update and delete come from the Deployment plan category, which Application Manager, Endpoint Security Manager, Policy and Profile Manager and School Administrator already carry, and Read Only Operator plus Help Desk Operator have read access. Deployments have no dedicated permission at all: launching one needs Read and Assign on the payload’s category, either Device configurations or Mobile apps. Designing the pattern and starting the run are different rights, which matters in an MSP where a technician hands the template to someone else.
  • Put the global exclusions in the plan, and remember that scope tags go on plans but not on deployments. The payload’s scope tags decide who can even see the deployment.
  • Keep ring one to a pilot group you can phone, respect the one-hour floor between rings, and remember the first ring’s start time is set at deployment time.
  • Write the exit plan down before you press Create: pausing halts progression, canceling stops what has not happened yet, and neither takes back what has.
  • If the payload is protected by MAA, tell the approver out of band. The request will not chase them and the deployment stays invisible until they act.

What the preview does not cover yet

Public preview means Windows 10 and later only, across four payload types: Endpoint security policies and Settings catalog policies for device configuration, plus Windows app (Win32) and Enterprise App Catalog apps. Win32 and catalog apps support the Required install intent only, so Available and Uninstall are out. For Enterprise App Catalog apps, updates with supersedence work with deployments while the automatic update option does not. The Deployments page has no sorting options and search matches the deployment name only. Automation exists in Graph beta through POST /deviceManagement/deployments with DeviceManagementConfiguration.ReadWrite.All, and beta endpoints change without much warning, so treat that as a lab experiment rather than a build target. Microsoft has not published an end date for the preview.

The feature is a good fit for the change you have been postponing because the pilot group routine is tedious: a packaging tool, a settings catalog policy, a security baseline setting that three sites will complain about. Put it behind ring one, watch it for a week, and let ring two do the arguing.

Sources