Approved managed Google Play app is invisible on devices: the Custom mode trap

You approved the app in the managed Google Play iframe, synced Intune, assigned it — and it simply isn't in the work Play Store on any device. No error, no warning. The likely culprit is a tenant-wide store layout setting called Custom mode, flipped by a collections edit that may have happened years ago.

The problem

The workflow looks textbook. An Intune admin approves a new app in the managed Google Play iframe, waits for (or forces) a sync so the app appears under Apps in the Intune admin centre, and assigns it as Available for enrolled devices to the right user group. Then the tickets arrive: users open the work Play Store on their Android Enterprise devices — work profile or fully managed — and the app is nowhere to be found.

What makes this one so disorienting:

• Every step reports success. The approval succeeds, the sync succeeds, the assignment shows the expected groups. There is no error to chase.
• Required deployments of the same app typically still install fine, because required installs do not depend on the storefront. Only apps users are supposed to find and install themselves go missing.
• Some apps are still visible, so the store is clearly working — in practice, apps already in collections remain visible, while anything outside a collection stays hidden, whether it was approved yesterday or years ago. Newly approved apps are simply the most common casualty.
• Re-approving the app, deleting and re-adding the assignment, and re-syncing the connector change nothing, which is where most admins burn their hours.

If that pattern matches — some apps visible, others silently missing, and no errors anywhere — the tenant is almost certainly in Custom mode.

Why it happens

The managed Google Play storefront that your users see has two layout modes:

• Basic (the default): every approved app is automatically visible in the work Play Store.
• Custom (collections): the store shows only apps that have been explicitly organised into collections. Anything not in a collection stays hidden from users, however correctly it is approved and assigned.

The trap is how a tenant moves between the two. Microsoft's troubleshooting documentation is unambiguous: "Custom mode is enabled automatically when you edit collections in the Managed Google Play iFrame. In this mode, newly approved apps remain hidden until you manually add them to a collection."

In other words, if anyone in your organisation has ever created or edited a collection in the iframe — even once, even as an experiment, even by a colleague who left years ago — the tenant silently switched to Custom mode and stayed there. From that point on, approving an app no longer makes it visible; it must also be added to a collection. Nothing in the approval flow, the Intune sync, or the assignment blade warns you that this second step now exists. The tenant state is invisible from the screens you normally work in, which is why this behaves like tribal knowledge rather than a documented setting.

The fix

Work through these in order — the first two rule out ordinary lag, the third is the actual fix.

1. Rule out sync lag first

• In the Intune admin centre, force a sync with managed Google Play rather than waiting for the scheduled one (open the Managed Google Play apps view and use the Sync button).
• Allow time for storefront changes to propagate to devices — this can take up to 24 hours. On the device, opening the work Play Store and pulling down to refresh the app listing sometimes hurries things along.
• Confirm the assignment itself: an Available assignment must target a group containing the affected users, and the app must actually be available for the device's country and configuration.

2. Check whether the tenant is in Custom mode

• In the Intune admin centre, go to Apps > All apps > Create > Managed Google Play app to open the iframe, and look at the store layout / organise apps view.
• If any collections exist, you are in Custom mode — and every newly approved app will stay hidden until it is added to one.

3. Fix it — two options

• Option A — keep Custom mode, add the app to a collection. In the iframe, add the newly approved app to an existing or new collection and save. This is the right choice if your organisation deliberately curates the storefront. The operational cost: adding an app to a collection becomes a permanent extra step in your app-approval runbook, so write it into the runbook now.
• Option B — reset the store layout to Basic. In the Intune admin centre: Apps > All apps > Create Managed Google Play app > Reset to Basic, then confirm. Per Microsoft: resetting deletes all existing collections, after which all approved apps become visible automatically — and any future edit to collections will switch the store straight back to Custom mode. Choose this if the collections were accidental in the first place and you want approval-equals-visible behaviour back.

After either change, allow a few minutes for propagation, then verify on a real device. If the reset fails, retry with an account that has the correct permissions before assuming a deeper fault.

Finally, leave a note in your team documentation stating which mode the tenant is in and why. The whole reason this trap exists is that the mode switch is invisible and outlives the person who caused it.

How Decolla handles it

Straightforwardly: it doesn't — and it wouldn't be honest to claim otherwise. Decolla provisions Windows devices over your own Intune and Autopilot tenant; it does not manage Android Enterprise or managed Google Play, so this particular fix will always be a manual one in your Google Play iframe.

The reason it belongs in our knowledge base is that it is a perfect specimen of the class of problem Decolla is built around on Windows: a hidden tenant-state trap where every console reports success, the failure is silent, and the fix is tribal knowledge buried in a troubleshooting doc. Windows and Intune provisioning is full of equivalents. Decolla's approach to them:

• The Library — a curated catalogue of 260+ pre-built, industry-tested policies, scripts and fixes, including recurring helpdesk fixes, so known traps are handled by tested configuration rather than rediscovered per tenant.
• A written, itemised plan before anything runs — every item states its delivery method and reversibility class (automatic, reversible, or flagged irreversible), and you approve the plan before Decolla touches the tenant. No silent state changes of the kind that caused this Google Play mess.
• Per-item rollback of Decolla's own changes — anything Decolla deployed can be backed out item by item. (That covers Decolla's changes only, not pre-existing tenant state.)

Decolla is pre-launch and currently waitlist-only at decolla.app.

Sources

• Microsoft Learn — Troubleshoot Managed Google Play apps on Intune-managed devices (section: "Newly approved Managed Google Play apps don't appear in the Play Store")
• Google Play Help — Troubleshoot problems with the managed Google Play Store (end-user side: missing apps and installation issues)