1 Design the rings once
| Practice | Why |
|---|
| Start with a small pilot | The first phase should be devices whose users report problems quickly — IT, key users, a test lab. A broken package then reaches ten devices, not a thousand. |
| Use the same ring collections or groups everywhere | Create them once, keep them up to date (query-based collections or dynamic groups), and save the phases as a template. Everyone then rolls out the same way. |
| Use Limit to instead of new groups | For an application only some people should have, keep the ring template and set Limit to to the audience. Creating a collection or group per phase per application leaves a lot to clean up later. |
| Do not mix users and devices Intune | Ring groups and the Limit to group must hold the same kind of members. A user group never matches a device group, so the phase would have no targets — or be skipped, if empty phases are skipped. |
| Keep the last ring for everyone | Make sure the rings together cover all devices or users that should get the software, or some will never get it. |
2 Choose realistic success criteria
| Practice | Why |
|---|
| Small rings: a number of devices | In a ring of 10, one switched-off laptop is 10 %. Number of devices successfully deployed = 8 is easier to reach than 95 %. |
| Large rings: a percentage below 100 | Some devices are always offline or broken. 85–95 % lets the rollout move on; the rest install later from the install collection or group anyway. |
| Never ask for more devices than the ring has | The phase then gets Not enough devices to complete. Remember that limits can make a phase smaller than its collection. |
| Available needs users Intune | With Assign as Available, a phase only succeeds as users install the application themselves from the Company Portal. Use a low number of devices as criteria, waiting hours, or Required for the pilot. |
| Know what Always Continue does | It switches off success criteria for all phased deployments: phases follow each other on their schedule whatever the results. Only use it if you do not want rollouts to wait for results. |
3 Plan for timing
| Practice | Why |
|---|
| Expect up to half a day between phases | A phase is only seen as completed at a compliance check (every 12 hours by default). Use Evaluate all when you want it now. |
| Use waiting hours for feedback time | Wait at least … hours guarantees the pilot runs for a while, even when it succeeds quickly. They count from the moment the previous phase was marked completed. |
| Remember time of day is an hour, and weekday is UTC | A phase with a time only starts in that hour; if it is missed (for example while the service was stopped), it waits for the same hour the next day. |
| Set the failure days to match the ring | The days next to A phase has not met its success criteria after also decide when the phase is marked failed. Give large rings more time than the default 7 days. |
| Use a deadline for must-have software | A security fix that every device needs by a date: the deadline starts all remaining phases at that time. |
| Plan ahead — you cannot edit a running rollout | Once the first phase has started, only the status-window actions remain. Use Start at to create it in advance and check it before it starts. |
4 Notifications, approval and permissions
| Practice | Why |
|---|
| Send mail to a shared mailbox | Approval requests and failures must reach someone who reads them, also during holidays. Templates keep the addresses, so set it once. |
| Approve production, not the pilot | Approval required on the first production phase gives a clear go/no-go after the pilot, without slowing down the pilot itself. |
| Give approvers only what they need | Approving, skipping, continuing and running phases are separate permissions in the security role. Approvers do not need to create or delete. |
| Deleting is not rolling back | Deleting a phased deployment stops it but uninstalls nothing. To roll back, remove the software with its uninstall deployment or a new version. |
5 With Robopack
| Practice | Why |
|---|
| Always a pilot phase in Patch Flow templates | New versions arrive by themselves, at any time. The pilot is the only thing between a faulty update and every device. |
| Upgrade only devices that have it | Tick the wizard’s Limit … to install collections / groups or program name, so an update never installs the application where it was not before. |
| Skip empty phases in those templates | With such limits, a ring without the application is otherwise stuck with No target resources and holds up the rollout. |
| Remove the devices from the previous version | So devices do not keep two versions in their install collections or groups. |
| Do not delete a template a flow uses | New versions are then imported but not rolled out. Change the template instead; the change applies from the next version. |
| One Intune template per tenant | Intune templates belong to their tenant’s groups. |
See also Automated patch flows – Best practices.
6 Keep it healthy
| Practice | Why |
|---|
| Glance at Last Run time | If Last Run time and Last Compliance Check on the Phased Deployments page are old, the SoftwareCentral Windows service is not running and no rollout moves. |
| Let old phased deployments go | Every phased deployment is evaluated at each run. Keep Remove Phased Deployments older than (days) at a sensible value, and delete rollouts you no longer need. |
| Look at stuck phases weekly | Sort out phases that are Failed, No target resources or Not enough devices to complete: continue, skip, or fix the collection or group. |
7 Troubleshooting
| Symptom | Cause | What to do |
|---|
| Last Run time and Last Compliance Check on the Phased Deployments page are old. |
The SoftwareCentral Windows service is not running. No rollout moves until it runs again. |
Start the SoftwareCentral Windows service. |
| A warning in the log: “The phased deployment service has run for n minutes. It is recommended to remove some phased deployments.” |
Every run looks at every phased deployment, and there are too many of them for a run to be quick. |
Delete the rollouts you no longer need, and lower Remove Phased Deployments older than (days) in Settings. |
| Status: “Package has been deleted” |
The software was deleted from SoftwareCentral. |
Delete the phased deployment. It cannot run without its software. |