Deployments (preview) in Intune: build a controlled rollout

A well-packaged application can still cause a widespread incident if its audience grows too quickly. Intune Deployments adds a scheduled way to expand delivery through rings. Use it to support a defined release process with owners and review points.

Plans, deployments and payloads

A plan is a reusable rollout template. A deployment executes a rollout for one supported app or policy. The public preview supports Windows Win32 and Enterprise App Catalog apps, Settings Catalog and endpoint security policies. Enterprise App Catalog supersedence updates are supported; its automatic-update option is not supported with deployments. A generic plan does not extend this preview support matrix. [1]

Ring progression follows timing criteria. Do not assume it waits for a success percentage or automatically approves a business change. Required assignments generally accumulate as rings activate. A final All devices or All users ring replaces earlier Required include groups; exclusions remain. Direct payload-assignment edits take precedence. [1]

Create the plan and deployment

1. Open Devices > Manage devices > Deployments > Deployment plans and create a plan.
2. Choose the platform, define rings and attach the intended Entra groups. Apply supported filters and exclusions. Intervals must be at least one hour.
3. Review scope tags and save. Treat subsequent plan edits as changes for future deployments; they do not update existing deployments. [2]
4. From Deployments, create a deployment and select an existing supported payload.
5. Load the plan, set its first start date and time, review targeting and create. A payload cannot have another scheduled or active deployment. [3]

A practical ring design

The following is a suggested operating pattern, not a Microsoft requirement. Use small representative cohorts before scaling. Agree review times before the scheduled next ring.

Capture the baseline assignment list before starting. An existing broad assignment can undermine the intended pilot boundary. Include remote users, slower connections and the actual security controls used in production. For application updates, validate supersedence, detection and uninstall behaviour separately.

Pause is not rollback

After creation, only the deployment name and description can be edited through the deployment. Assignment collisions can pause a ring with an error; resolve the colliding payload assignment before resuming. [3]

Before using this on a business-critical app, rehearse the response to a failed pilot: who pauses expansion, who decides whether to uninstall or redeploy, which users receive communications, and what proves recovery. Keep the known-good installer and its prerequisites available.

Permissions and approval

Plan permissions are separate from payload permissions. Creating a deployment requires Read and Assign in the relevant app or device-configuration category. Deployment visibility follows the payload’s scope tags. Where Multi Admin Approval protects the payload, supported actions including creation, resume and cancellation can require approval. A creation awaiting approval may not yet appear in the list. [4]

My recommendation is to nominate a change owner and deputy who can both interpret deployment status and respond within the next-ring window. Keep preview adoption limited until failure handling and operational ownership are proven.