Required vs Available app assignments in Intune

What is the difference between Required and Available?

The intent does not change the package or the install command — it changes who triggers the install and when. A Required app is installed silently in the background by the device, on Intune’s schedule, whether or not anyone opens an app. An Available app sits in Company Portal until the assigned user clicks Install.

Both intents run the same install command, are gated by the same requirement rules, and are confirmed by the same detection rules. The difference is purely about consent and automation: Required removes the choice from the user, Available hands it to them.

When should you use Required?

Choose Required when the app must be on the device regardless of user behavior: endpoint protection agents, VPN clients, a standard browser, line-of-business tooling, or anything tied to compliance. Required is the right choice for a managed baseline because it does not depend on a user remembering to install anything.

Required works with both device groups and user groups. Device targeting is ideal for shared or kiosk machines where no specific user owns the device. Because Required installs without asking, always start with a small pilot group, confirm install and detection succeed, and review the app’s per-assignment reporting before you widen the scope.

When should you use Available?

Choose Available when installation should be the user’s decision: optional productivity tools, department-specific software, or anything you want to pilot with real users before making it Required. The app appears in Company Portal for everyone in the targeted group, and only the people who actually need it install it — which keeps unnecessary software off most devices.

The critical constraint: Available is for enrolled devices and requires a user. You cannot assign Available to a device-only group, because Company Portal runs in the context of a signed-in user. If your app is configured to install in User context, the user must be signed in for the install to complete. For app-wide installs, use System context regardless of intent.

How long does a Required install take to appear?

This is the question that generates the most “it isn’t working” tickets. Win32 app and PowerShell policy is processed by the Intune Management Extension (IME), not the general MDM channel, and the two run on different schedules:

• IME Win32 policy cycle: roughly every 1 hour, and also right after a device restart or when the IME service restarts. This is what actually pulls and runs a Required Win32 install.
• General MDM device check-in: a variable schedule (commonly around every 8 hours, more frequent just after enrollment). This handles policy and compliance, not the Win32 install loop — do not wait on it to test app delivery.

To test without waiting, trigger a sync from Settings > Accounts > Access work or school > Info > Sync, or from Company Portal. If a target device is stuck, restarting the IME service forces a fresh Win32 policy evaluation:

Restart-Service -Name IntuneManagementExtension -Force

For the full picture of check-in timing and manual sync options during testing, see how Intune device sync works.

What happens after you assign an app?

Whichever intent you pick, the device runs the same evaluation sequence. Requirement rules decide whether the device is even eligible; detection decides whether the app is already present; only then does the install command run.

What does the Add group dialog look like?

On the Assignments tab you add one or more groups under each intent, optionally with excluded groups. Use exclusions deliberately: an exclude on a Required assignment does not uninstall the app from devices that already received it.

What does the end user see?

The intent shapes the entire end-user experience. A Required install happens quietly in the background; the user may see a toast notification when it completes but takes no action. An Available app only appears as an installable tile in Company Portal, where the user starts the install and watches its status.

• Required: no prompt to start; installs on the IME schedule; may surface a completion toast.
• Available: appears in Company Portal with an Install button; the user controls timing and sees live status.
• Uninstall: the app is removed on the next check-in; nothing for the user to do.

If an Available app is missing from a user’s Company Portal, check that the assignment targets a user group the person belongs to, that the device is enrolled, and that the right user is signed in.

How do requirement and detection rules affect the choice?

Requirement and detection rules apply identically to Required and Available — they are not part of the intent decision, but they determine whether either intent actually does anything. A device that fails a requirement rule (wrong OS architecture, below the minimum OS, insufficient disk space) will silently be considered “not applicable,” so a Required app simply will not install and an Available app may not appear as installable.

Likewise, if detection already reports the app as present, neither intent will reinstall it. When an assignment “looks correct but nothing changes,” verify the requirement rules and detection logic before suspecting the intent.

What about the Uninstall intent?

Uninstall is the third intent and the opposite of installing: it runs the app’s uninstall command on targeted devices that received the app through this Intune deployment. It is not the same as removing a Required assignment — deleting an assignment stops future installs but does not remove the app from devices that already have it. Use Uninstall explicitly, and confirm the uninstall command runs silently before targeting production devices.