Removing an app's assignment does not uninstall it — Intune's deliberate but surprising design

You deleted the Required assignment, the portal looks clean, and yet the software is still installed and running on every device. That is not a bug. Intune assignments are instructions, not desired state — and removing an instruction is a no-op on devices that already acted on it. Here is why, and the correct decommission pattern.

The problem

You assigned an app as Required to a group, it installed across the fleet, and now you want it gone — you are decommissioning it, reclaiming licences, or replacing it with something better. So you do the obvious thing: remove the group from the assignment, or delete the assignment altogether.

Nothing happens. The app stays installed. It keeps running, keeps auto-starting, keeps consuming licences. There is no error, no failure report, no warning — because from Intune's point of view, nothing failed.

“Removing a group assignment does not remove the related app. The installed app will remain on the device.”

— Microsoft Tech Community discussion, App assignment — removing a required app

Most admins discover this the hard way: weeks after “removing” an application, a licence audit or a user ticket reveals it is still on every machine that ever received it. Only devices that had not yet installed the app are unaffected — they simply never receive the install instruction.

Why it happens

Assignments are instructions, not desired state

Intune app assignments come in three intents:

Intune does not reconcile “what is installed” against “what is assigned” and remove the difference. Each assignment is a discrete instruction; deleting the instruction means Intune stops issuing it — the absence of an assignment is never interpreted as “remove this”.

This is deliberate

Group membership in Entra ID churns constantly — dynamic groups re-evaluate, users move departments, devices are re-categorised. If falling out of an assignment group triggered an uninstall, every transient membership change would rip working software off devices mid-use. Treating un-assignment as a no-op is the safe default; it just surprises anyone who expects configuration-management-style state reconciliation.

The conflict trap

There is a second surprise waiting: Intune resolves assignment intents per device or user, across all of their group memberships. If a device or user receives both a Required and an Uninstall intent for the same app through any of its groups, Required wins. Leave a device in Group A (carrying the Required assignment) while adding it to a new Group B (carrying the Uninstall assignment) and it still resolves to Required — the app never uninstalls. Adding an Uninstall intent without first removing the Required one does nothing, which is why some admins conclude the Uninstall intent “doesn't work” either.

The fix

Uninstalling is an explicit action in Intune. The reliable decommission pattern:

1. Create a dedicated decommission group (e.g. uninstall-appname). A dedicated group gives you a controlled blast radius and a clean audit trail.
2. Remove the Required intent first. Take the target devices/users out of any group carrying the Required assignment, or delete that assignment. Skip this and the Required intent silently overrides your Uninstall intent on every device or user that still receives both.
3. Assign the app with the Uninstall intent to the decommission group.
4. Pilot on one device before scaling. For Win32 apps, the Uninstall intent runs the uninstall command you specified when the app was packaged — if that command string is wrong or the app's uninstaller needs switches you never tested, the intent fails quietly. Line-of-business MSI apps uninstall by product code, which is generally dependable. Confirm the detection rule returns “not installed” after removal, otherwise Intune will report the uninstall as failed even when it worked.
5. Move devices into the group in waves and let them check in (or trigger a manual sync from Company Portal or Settings to hurry a pilot device along).
6. Verify, then clean up. Watch the app's Device install status report until the fleet shows the app removed. Only then delete the Uninstall assignment, the decommission group, and — if you are fully retiring it — the app object itself.

Two related tips:

• Replacing an app rather than removing it? Win32 supersedence can uninstall the old application as part of deploying its replacement — one assignment instead of a co-ordinated remove-and-add.
• Fix this at packaging time, not decommission time. Test the uninstall command in the same pilot as the install, before the first production deployment. An app whose removal path was never proven is an app you cannot cleanly retire later.

How Decolla handles it

This niggle is Decolla's reversibility promise in miniature. Decolla provisions Windows devices over your own Intune/Autopilot tenant, and before anything runs it produces a written, itemised plan: every item states its delivery method and its reversibility class — automatically reversible, reversible, or explicitly flagged irreversible. You approve that plan before deployment starts.

Concretely for apps: every install in a Decolla plan has a documented, tested uninstall path before it is ever deployed — the removal route is proven at build time, not discovered at decommission time. If you later approve a rollback, Decolla removes that item using the path it already validated, per item, rather than leaving you to reverse-engineer uninstall strings across the fleet.

To be clear about the limits: Decolla's rollback covers Decolla's own changes only. It will not uninstall applications you assigned yourself outside Decolla — for those, the Uninstall-intent pattern above is the way to do it. Decolla is currently pre-launch; you can join the waitlist at decolla.app.

Sources

• Microsoft Tech Community — App assignment: removing a required app
• Microsoft Learn — Assign apps to groups with Microsoft Intune (assignment intents and conflict resolution)