Microsoft Intune App Assignments: How Required, Available, Update-Only, and Uninstall Really Work
Intune Assignment Types Explained
How Required, Available, Update-Only, and Uninstall assignments really work in production
When you assign an app in Microsoft Intune, you are not just deciding who gets it. You are deciding the install behavior, the user experience, and how updates and removals will be handled over time.
Most app deployment issues in Intune come from one of these mistakes:
- Using Required when the app should be optional
- Using Available but expecting auto-install
- Updating apps in a way that accidentally installs them everywhere
- Assigning Uninstall while another policy still forces the app back
This post breaks down the main assignment types and how to choose the right one.
What “assignment” means in Intune
An assignment answers two questions:
- Who is targeted
- Users or devices
- Included groups and excluded groups
- Optional use of filters for precision
- What action Intune should take
- Install automatically
- Offer it in Company Portal
- Update it only when already present
- Remove it
If you get both parts right, deployments become predictable. If you get either part wrong, you get weird results like installs triggering on the wrong device, apps showing up where they should not, or updates not applying.
1) Required assignment
What it does
A Required assignment tells Intune: install the app automatically for the targeted users or devices.
What users see
- Installation typically happens in the background
- In many cases the user does not need to do anything
- Some apps still pop prompts depending on how they are packaged and installed
Best use cases
- Core business apps that everyone must have
- Security tools and management agents
- VPN clients and certificate tools
- Anything that is part of your “minimum viable workstation”
Common gotchas
- User-based required installs can follow a user to multiple devices. That may be good or bad depending on your environment.
- Device-based required installs are better for shared devices, kiosks, and controlled rollouts.
- Make sure detection rules are solid. Bad detection is the #1 reason Required deployments loop or fail.
2) Available assignment
What it does
An Available assignment tells Intune: make the app optional and expose it in Company Portal so the user can install it.
What users see
- The app appears in Company Portal
- The user chooses when (or if) to install it
Best use cases
- Optional utilities and productivity tools
- Department-based apps where not everyone needs it
- Self-service catalogs
Common gotchas
- If you do not scope properly, you can accidentally offer apps to the wrong users.
- Filters are extremely useful here. For example, only show certain apps on corporate Windows 11 devices.
3) Update-Only assignment (patching without expanding footprint)
What it does
Update-Only means: update the app if it already exists, but do not install it on devices that do not have it.
This is the “keep it patched but don’t push it everywhere” approach.
What users see
- Nothing new appears in Company Portal
- No surprise installs
- Existing installs stay current
Best use cases
- Apps that are optional but must remain updated when present
- Environments where the initial install is handled elsewhere (imaging, manual install, another deployment method)
- Reducing risk during patch cycles
Common gotchas
- If your detection logic is wrong, Intune may treat the app as missing and skip updates, or repeatedly try to apply them.
- Make sure you understand where the app is installed and how it is detected (machine vs user context).
4) Uninstall assignment
What it does
An Uninstall assignment tells Intune: remove the app from targeted users or devices.
Best use cases
- Removing legacy software
- Cleaning up insecure or unsupported apps
- Replacing old apps during migrations
Common gotchas
- If the same app is also Required somewhere else (even indirectly), you create a loop:
- One assignment removes it
- Another assignment reinstalls it
Result: endless churn, failed installs, angry users
- Keep your assignments mutually exclusive and document your intent.
Quick decision table
| Goal | Use this assignment |
|---|---|
| Everyone must have it | Required |
| Optional, user self-service | Available |
| Patch it only where it already exists | Update-Only |
| Remove it from devices | Uninstall |
Real-world strategy that works in enterprises
Use deployment rings
A simple model:
- Pilot group (IT or test users)
- Early adopters
- Broad deployment
- Exception group (break-glass exclusions)
This avoids “big bang” failures and gives you rollback space.
Be deliberate: user vs device targeting
- Target users when the app follows the person (common in knowledge worker scenarios)
- Target devices when the device role matters (shared, kiosk, frontline, lab devices)
Use filters to avoid group sprawl
Filters let you keep groups stable while still being specific, such as:
- Corporate-owned only
- Windows 11 only
- Exclude shared devices
- Exclude devices without a certain tag
Keep assignments clean
For every app, aim for one of these patterns:
- Required only
- Available only
- Required + Uninstall (only during migrations, with clean scoping)
- Available + Update-Only (common for optional apps you still want patched)
Conclusion
Intune assignment types are simple on the surface, but the impact is big. Required drives automation, Available enables self-service, Update-Only keeps patching tight without expanding installs, and Uninstall removes technical debt.
