'Available' app assignments only work on user groups — device groups silently do nothing

You assigned an app as "Available for enrolled devices", targeted your device group, and Company Portal shows nothing — no error at assignment time, no failure in the console, no clue. For almost every app type that combination is a documented no-op. Here is the full intent-by-target support table and how to retarget safely.

The problem

You add an app in Intune, set the assignment intent to Available for enrolled devices, and target an Entra device group — often a dynamic Autopilot group, because that is the natural unit when you think in terms of machines. The admin centre accepts the assignment without complaint. Then: nothing. The app never appears in Company Portal on any of those devices. Install status reports nothing, because Intune never attempted anything.

This bites hardest during Windows provisioning, where device groups are how everything else (configuration profiles, compliance policies, Required apps) is usually scoped. It also produces a maddening variant: the app shows up for some users and not others, sending you down rabbit holes of Company Portal resets and device syncs — as in the Tech Community thread linked below — when the actual cause is the target group's membership type or the device's primary user.

The core trap: Intune does not validate group membership type at assignment time. An Entra security group can contain users, devices, or both, and the assignment saves either way. The failure is completely silent.

Why it happens

Available is a user-context intent. Company Portal runs as the signed-in user and resolves the available-app catalogue against that user's group memberships. A device group never enters that query path, so for almost every app type an Available assignment to a device group is never evaluated at all. Microsoft's documentation states it plainly:

"For almost all app types and platforms, Available assignments are only valid when assigning to user groups, not device groups. Win32 apps can be assigned to either user or device groups." — Microsoft Learn, Assign apps to groups with Microsoft Intune

On Windows that means Win32 is the lone exception: Microsoft Store apps (the WinGet-backed type), Microsoft 365 Apps, line-of-business MSI and web links all honour Available on user groups only. (The other documented exception is on Android: Available for enrolled devices is supported for device groups on Android Enterprise fully managed and corporate-owned work profile devices.)

Underneath sits a broader architectural point. User-targeted and device-targeted assignments are synchronised and evaluated through different query paths, on different schedules, against different identities (the user versus the machine). Andrew Taylor's rule of thumb, from his write-up on the subject:

"NEVER mix device and user based targeting due to the way Intune synchronises and queries groups." — Andrew Taylor, Intune user vs device targeting

Mixing the two for the same app also drags you into Microsoft's intent-conflict resolution table (User Available + Device Uninstall resolves differently from User Uninstall + Device Required, and so on), and assignment filters are evaluated after intent conflicts are resolved — so filters may not behave as expected on a conflicted app.

One further silent failure in the same family: even with a correct user-group Available assignment, the app only appears in Company Portal for the device's primary user (the user who enrolled it, for user-enrolled devices). Secondary users on a shared machine will not see it, which is why "works for some users, not others" is the classic presentation.

The fix

1. Know which combinations Intune actually honours

The intent-by-target support matrix for Windows app assignments (UI labels quoted verbatim):

2. Audit your existing Available assignments

For each app assigned as Available, open the target group in Entra and check what it actually contains. If the members are device objects and the app is not Win32, that assignment has been doing nothing since the day it was created. To sweep the whole tenant via Graph:

GET https://graph.microsoft.com/v1.0/deviceAppManagement/mobileApps?$expand=assignments

Filter the results for assignments with "intent": "available", take each target.groupId, then check the group's members for entries of type #microsoft.graph.device:

GET https://graph.microsoft.com/v1.0/groups/{id}/members

3. Retarget to user groups — and scope by device with a filter, not a device group

Reassign Available intents to user groups. If you need the app offered only on certain hardware (say, corporate laptops but not kiosks), keep the user group as the target and add a device-based assignment filter — this is Andrew Taylor's recommended pattern, and it preserves the user-context query path Company Portal depends on.

4. Do not mix user and device targeting for the same app

Pick one axis per app and stay on it. If the same app must be Required for one population and Available for another, target both intents at user groups. Mixed-axis assignments put you at the mercy of the conflict-resolution table and of two group-sync paths that do not complete at the same time.

5. If a user still cannot see an available app

Check the device's primary user (device blade in the Intune admin centre). Available apps surface in Company Portal only for the primary user of the device, so a correct assignment can still be invisible to a colleague borrowing the machine.

How Decolla handles it

Decolla (a product of The Cloud Platform Ltd, currently pre-launch) provisions Windows devices over your own Intune and Autopilot tenant, and its defence against this niggle is structural: nothing deploys without a written, itemised plan that you approve first. For every item in a build, the plan states the delivery method up front — including how each app assignment is targeted — so an "Available to a device group" no-op is impossible to slip into a build unseen. The Library's pre-built, industry-tested items carry known-good assignment patterns rather than leaving intent-versus-target choices to be re-derived by hand each time, and each item is classed for reversibility, with rollback covering the changes Decolla itself made.

To be clear about the boundary: Decolla governs its own deployments. It does not retro-audit assignments you created by hand in the admin centre before Decolla was involved — for those, the Graph sweep in step 2 above is the right tool today. If you would like the plan-first approach for future builds, the waitlist is open at decolla.app.

Sources

• Assign apps to groups with Microsoft Intune — Microsoft Learn
• Intune user vs device targeting — Andrew Taylor
• Available app assignments not showing in Company Portal of certain devices — Microsoft Tech Community