Disable, deprovision, or delete? What actually happens to a Chromebook

A Chromebook comes back broken, or a student graduates, or a device walks out of the building and does not come back. You open the Admin Console and there are two buttons where you expected three, and nothing on screen tells you which one you want.

Worse: one of those buttons asks you a follow-up question that quietly decides whether you keep a license you paid for.

The short answer

There are two actions and an undo, not three actions.

Disable blocks the device. It stays enrolled, stays managed, and stays yours. Reversible with one click.

Deprovision takes the device out of management. Policies come off and the record stays. What happens to the upgrade depends on which kind you hold and, for one of them, on a reason code you are asked to pick. Reversible only by wiping and re-enrolling.

Delete is not one of them — not in the API, and not as an action on an enrolled device. If you have been looking for it, that is why you could not find it.

Disable

Disabling is the lost-and-stolen tool, and it is the only one of these that is genuinely, cleanly reversible.

The device stays enrolled in your organization and keeps its Chrome upgrade. Nobody can sign in until you re-enable it, and you can put a message and a contact number on the lock screen — which is the single most effective thing you can do to get a device back from a family that has moved.

The record stays in its organizational unit with a status of Disabled. Re-enabling puts everything back exactly as it was.

Reach for this when the device might come back. A device you disabled in October and recovered in January costs you nothing and needs no re-enrolment.

Deprovision

Deprovisioning ends management. Per Google, it "removes all policies that were on the device as well as device-level printers and the ability to use the device as a kiosk."

What it does not do is remove the device from your tenant. From Repair, repurpose, or retire ChromeOS devices:

Deprovisioned devices remain in their organizational unit, even though you no longer manage them.

That is by design and it is useful — it is how you answer "did we ever own this serial number" two years later. It is also why your device totals stop agreeing with each other once you have deprovisioned at scale, which is a whole problem of its own.

Deprovisioning is reversible in the sense that the hardware can be enrolled again after a wipe. Whether that costs you anything is the question the next section answers — and the answer is different for each of the three upgrade types, so "deprovisioning spends a license" is not a rule you can carry around.

There is no delete for an enrolled device

This is the part that sends people in circles, so it is worth being precise rather than merely blunt.

There is no delete action for an enrolled ChromeOS device record. Google's Directory API exposes exactly these methods on a ChromeOS device: get, list, moveDevicesToOu, patch, update. There is no delete method. The endpoint that changes a device's state, batchChangeStatus, supports exactly three actions:

DEPROVISION — "Deprovisions a ChromeOS device"
DISABLE — "Disables a ChromeOS device"
REENABLE — "Reenables a ChromeOS device to be used after being disabled"

No delete. No remove. The device record is not something Google gives you a way to destroy.

Deletion does appear elsewhere in Chrome management — pre-provisioned records that were never enrolled are a different case — but the lifecycle of a managed, enrolled device runs on disable and deprovision, not delete.

So when a colleague says they deleted a Chromebook, they deprovisioned it, and the record is still sitting in the organizational unit it was in. Every count you take afterwards has to account for that.

The deprovision reason is a license decision

Here is the part that actually costs money, and it is presented as a routine dropdown.

When you deprovision, Google asks why. The options are:

• Same model replacement — a hardware fault, replaced with the same or a like model from a repair vendor or the manufacturer
• Different model replacement — upgrading or replacing with a newer model
• Retiring from fleet — reselling, donating, or permanently removing the device
• ChromeOS Flex upgrade transfer — replacing Flex devices with Chromebooks within a year

That dropdown is not record-keeping. Where your upgrade can move between devices at all, it is what determines whether it comes back in a form you can use — and whether it can move at all is the next section.

Three upgrade types, three different rules

This is where districts get caught, because the three are easy to blur and Google treats them very differently. From Use Chrome upgrades:

Standalone perpetual and bundled are not the same thing, and that is the confusion worth clearing up. Both last the life of the device, so they feel alike — but a perpetual upgrade was purchased separately and can move under narrow conditions, while a bundled one came attached to the hardware and stays there.

Read the perpetual rule carefully: same model, and a hardware issue. Both conditions, not either.

Where the dropdown actually shows up

Google gives standalone perpetual upgrades a status in the console, and the two that matter read like the two ends of that dropdown:

Retired — "perpetual upgrades that were enrolled to a device that has since been retired, and the upgrade cannot be transferred or re-used on a different device"

Conditionally available — "previously enrolled and later unenrolled for RMA, warranty, or repair reasons, and are only available to be reused on a same model device"

Read those together and the dropdown stops looking like paperwork. One of those statuses can be used again on the right hardware. The other cannot be used again at all.

So if you hold perpetual upgrades and you deprovision a faulty device under Retiring from fleet because it was the quicker click, the documented endpoint for that license is one that "cannot be transferred or re-used on a different device." The hardware was leaving either way. The license is the part you could still have kept.

Two limits worth stating. This is specific to standalone perpetual upgrades — fixed-term ones transfer freely and bundled ones never move, so the reason code matters far less for either. And Google documents the statuses and their meanings without publishing a line-by-line map from each dropdown option to each status; joining "Retiring from fleet" to Retired, and the repair reasons to Conditionally available, is our reading of it rather than a quote.

Choosing by situation

Lost, might come back. Disable, with a lock-screen message and a phone number. Do not deprovision — you would be giving up the license and the management on a device you may well recover.

Stolen, not coming back. Disable first, immediately. Deprovision later as a fleet-cleanup decision, once you have decided how you are tracking write-offs.

Broken, going to the vendor. Deprovision as Same model replacement. This is the case the perpetual transfer rule was written for, and it is the one where picking the convenient option instead is most expensive.

Refresh — old model out, new model in. Deprovision as Different model replacement. If your upgrades are perpetual, expect to buy licenses for the new hardware; that is the rule, not a mistake you made.

Graduating cohort, devices retained. Nothing to do at the device level. Deprovisioning a device you are keeping creates re-enrolment work for no gain, and depending on your upgrade type it may cost you more than that.

Retired, sold, or donated. Deprovision as Retiring from fleet, with the factory reset option, so nothing of yours leaves with it.

Common mistakes

Deprovisioning to "clean up the list." It does not clean up the list. The record stays in the organizational unit. You have ended management of a device you still own and changed nothing you can see — and depending on the upgrade type, you may have made the device more expensive to bring back.

Using deprovision for a lost device. Disable does what you want, keeps the device manageable, and costs nothing to undo.

Picking the deprovision reason by whichever is nearest the mouse. It is the only part of this that is hard to undo.

Assuming an "empty" organizational unit is empty. Deprovisioned devices are still in it, which matters the day you try to delete that OU.

Expecting a delete button. There isn't one. Nothing is broken and nothing is missing from your admin role.

What to do about it

Write down the mapping — situation to action to reason — and put it where whoever is processing devices can see it. This is a decision made hundreds of times a year, usually quickly, often by whoever is at the bench that day, and the expensive part is invisible at the moment of clicking.

Then check which upgrades you actually hold before you write that mapping. Perpetual and annual licenses make the same dropdown mean different things, and a rule sheet written for the wrong one is worse than none.

Sources

• Repair, repurpose, or retire ChromeOS devices — Chrome Enterprise and Education Help
• Use Chrome upgrades — Chrome Enterprise and Education Help
• customer.devices.chromeos.batchChangeStatus — Google for Developers
• chromeosdevices resource — Google for Developers

Related field guides

• Why your ChromeOS device counts don't match
• The summer rollover checklist

Getting this wrong across a few thousand devices is how you discover that a dropdown was a purchasing decision. ORINEX Workspace exists because these choices are made in bulk, under time pressure, by people who should not have to hold Google's license transfer rules in their head. What ORINEX Workspace does.