Work profile vs fully managed vs COPE vs dedicated: which Android Enterprise mode do you actually need?

Intune offers four Android Enterprise management modes with confusingly similar names, and the mode is locked in at enrolment — pick wrong and the only way out is a factory reset. Three questions get you to the right one first time.

The problem

You open Devices > Android > Enrollment in Intune and find four Android Enterprise options: personally-owned devices with work profile, corporate-owned devices with work profile (COPE), corporate-owned, fully managed user devices (COBO) and corporate-owned dedicated devices (COSU). Two of them have almost identical names. None of the blades tells you which one you need.

The stakes are higher than they look, because the choice is effectively permanent per device:

• Switching modes means a factory reset. A device enrolled fully managed cannot be re-homed into a work profile mode (or vice versa) in place. Microsoft staff confirmed on Q&A that dedicated, fully managed and corporate-owned work profile enrolment all require a freshly wiped device — and that this is an Android platform constraint, not an Intune design choice.
• The enrolment path can silently deliver the wrong mode. Admins report devices landing in a different mode than the token they used was meant for — one Microsoft Q&A poster using a corporate-owned work profile QR code found that "everytime the device gets enrolled with Corporate-owned, fully managed user device".
• Leftover enrolment state blocks the new mode. In a Prajwal Desai forum thread, apps refused to install during corporate-owned work profile enrolment because the device had previously been enrolled fully managed — as the thread concluded, "If the device has already been enrolled in a fully managed profile with Microsoft Intune, it won't allow you to enroll it in a different profile." The fix was a factory reset before re-enrolling with the COPE profile.

The people who hit this hardest are teams migrating off the deprecated Android Device Administrator channel, and anyone doing their first corporate Android rollout: mis-pick for a hundred devices and you are looking at a hundred factory resets.

Why it happens

Three separate causes stack up.

1. The management role is baked in at first boot

During provisioning, Android grants the Device Policy Controller (Android Device Policy) one of two roles: device owner (fully managed and dedicated modes) or profile owner (the two work profile modes). Android does not permit that role to change on a provisioned device. That is why every mode change routes through a factory reset — Intune is simply surfacing Android's rule.

2. Google defines three solution sets; Microsoft exposes four

Google's Android Enterprise documentation describes three deployment scenarios; Intune splits corporate-owned devices with a work profile out as a distinct fourth enrolment type. That is how you end up with two near-identical "work profile" options whose difference — who owns the device — completely changes what IT can enforce.

3. Some enrolment paths cannot deliver COPE, and fall through to fully managed

The mode is determined by the enrolment profile whose token the device consumes at setup, and not every provisioning method can carry a COPE token:

• The afw#setup DPC-identifier (token entry) method only supports full device management provisioning — Microsoft's documentation notes it is not supported for corporate-owned work profile on Android 11.
• NFC provisioning is likewise not supported for COPE on Android 11.
• When you link a Google zero-touch account to Intune, the automatically created default configuration uses a fully managed token — and it overrules the default configuration set in the zero-touch portal. Microsoft's own docs warn against linking the account at all if you want zero-touch COPE or dedicated enrolment.

So an admin who built a COPE enrolment profile, but whose devices actually consume the zero-touch default configuration or the DPC-identifier path, watches every device arrive as "Corporate-owned, fully managed user device" — exactly the behaviour reported on Microsoft Q&A.

The fix

Step 1: answer three questions per device group

1. Does the organisation own the device? No → personally-owned work profile (BYOD). Stop here — the corporate-owned modes require a factory-reset provisioning flow you cannot reasonably impose on a user's own phone, and full device control of personal hardware is a privacy problem you do not want.
2. Is it a single-purpose or shared device with no dedicated user? Kiosk, scanner, digital signage, shared frontline handset → dedicated (COSU).
3. Does the assigned user get sanctioned personal use? Yes → COPE (corporate-owned with work profile). No — work-only device → fully managed (COBO).

Step 2: sanity-check against the capability table

Step 3: make the enrolment path match the mode

• Create a separate enrolment profile per mode in Intune and name it unambiguously — each profile issues its own token and QR code. Never reuse a token across intents.
• For COPE on current Android, enrol by QR code, zero-touch or Knox Mobile Enrollment — not afw#setup token entry or NFC.
• If you use Google zero-touch for COPE or dedicated devices, do not link the zero-touch account to Intune — build the configuration in the zero-touch portal with your enrolment profile's token in the DPC extras JSON, because the Intune-linked default configuration carries a fully managed token and overrules the portal.
• Pilot one device per mode and confirm in the Intune admin centre that it reports the management mode you intended before bulk rollout. Do not let users restart mid-enrolment — a device that restarted can look enrolled while not registering with Intune.
• If a device came in on the wrong mode: wipe it, factory reset, re-enrol with the correct profile's token. There is no in-place conversion — budget for it once, not repeatedly.
• Write the decision down per device group — owner, personal-use policy, chosen mode, enrolment method — so the next admin does not re-litigate it against live devices.

How Decolla handles it

Straight answer: Decolla does not manage Android devices, so it will not pick your Android Enterprise mode or run your Android enrolment. Decolla is zero-touch Windows device provisioning, running over your own Intune and Autopilot tenant.

What Decolla does do is institutionalise the discipline this article is really about: decide and document before anything irreversible runs. On the Windows side, Decolla's wizard walks a curated catalogue of 260+ items and produces a written, itemised plan — delivery method and reversibility class recorded per item, with irreversible items explicitly flagged — that you approve before a single change is made in your tenant. Anything Decolla itself changes can be rolled back per item.

The Android mode choice is exactly the class of decision that plan-first approach exists for: cheap to record up front, expensive (a factory reset per device) to discover late. If you run Windows estates alongside your Android fleet, Decolla is pre-launch and open for the waitlist at decolla.app.

Sources

• Microsoft Q&A — Corporate-owned work profile enrollment (factory reset required; Android platform constraint)
• Prajwal Desai forums — Apps are not installing at the time of Android enrollment (corporate-owned with work profile)
• Microsoft Learn — Enroll Android Enterprise dedicated, fully managed, or corporate-owned work profile devices in Intune