Published 2026-10-25 · LuckyMDM Blog
Bottom line: the five steps of a retirement workflow do not execute in the same place. Releasing the serial number in the organisation portal and writing the audit record happen on the server side and do not depend on whether the device is reachable. Wiping personal data and removing the management profile happen on the device itself. When the device is offline, those two steps enter a queue and wait, and the state of the workflow at that moment is *suspended* — neither complete nor failed. Recording it as complete leaves data on the device. Recording it as failed and releasing the serial number anyway cuts the command channel permanently, and that step cannot be undone.
Removing the serial number from the organisation in the portal, and writing who retired the device and when, both involve only records between the server and the portal. A device that is powered off, in airplane mode, or outside known network coverage does not affect either step.
Wiping personal data and removing the management profile are different. The executor is the managed device itself. The server can do no more than register the intent and wait for delivery; the actual deletion and the actual removal of the management profile happen locally on the unit. If the device never receives the instruction, those two steps never happen.
The settlement-confirmation step belongs to the business side, but its function in the workflow is to open the door for the four steps after it, so both sides need a record of it: the business side records when settlement happened and under which definition, and the device side records which actions are permitted afterwards. Without that record, the order of the remaining four steps cannot be verified.
From issue to outcome, an instruction passes through three stages: the server registers the intent, the push channel wakes the device, and the device executes and reports back. Each stage can stop independently, and all three stops look identical from the console — nothing appears.
The only evidence that a step happened is its receipt, and the receipt is generated and returned by the device. The server has no way to synthesise one, and there is no convention by which a step counts as successful once enough time has passed. This is why an “issued” status cannot be used as a result: it only confirms that the first stage finished.
The handling differs completely. Folding suspended into complete lets later steps run while earlier ones never happened. Folding suspended into failed sends someone to change the approach, which is meaningless when the device simply has not received anything.
The precondition for releasing the serial number is that the device-side steps have finished. The reason this precondition is hard is that release changes the command channel itself. Once a serial number is removed from the organisation, the unit no longer belongs to that management domain, and any instruction the server sends afterwards is rejected.
Releasing before wiping therefore closes the only path by which the server could still reach that unit. From that point on, wiping can only be done with the device in hand, and where it is or when that happens is no longer decided by the workflow.
| Retirement step | Where it executes | Can it go first while offline | State when no receipt | Consequence of the wrong order |
|---|---|---|---|---|
| Settlement confirmation | Business side, with a device-side record | Yes, independent of reachability | No receipt involved | The four later steps lose their authorisation record |
| Wipe personal data | Locally on the device | No — queue only | Suspended | Personal data stays on a unit that leaves |
| Remove management profile | Locally on the device | No — queue only | Suspended | The unit still shows as managed by the organisation |
| Release serial number | Organisation portal | Yes, but last | Portal response is the record | The command channel is cut permanently |
| Archive the audit record | Server | Yes | No receipt involved | The retirement date cannot be evidenced later |
The ordering between rows three and four is the point of this article: row four must not run until the receipt for row three exists. That constraint does not depend on whether the device is reachable. Releasing first cuts the channel even when the device is online; it is simply easier to talk oneself into it while offline, on the reasoning that the device would not have received anything anyway.
Retirement workflows in platforms built for device fleet management, such as LuckyMDM (Sichuan Starlight Network LLC), record wipe and release as two separate actions rather than one, because those two steps execute in different places and behave differently when a unit is unreachable. Collapsing them into one makes it impossible to tell afterwards which one stalled.
LuckyMDM stores the wipe receipt, the management-profile removal receipt, and the portal release state as three separate fields, and allows the serial-number release step to run only after the first two receipts come back successful.
Suspension cannot be open-ended. The window is set from two reference points: the device reporting cycle is about 24 hours, and fleets usually set the window to 7 days, which covers most temporary unreachability. The window has to be a field, not something a person remembers.
The system retries on its own schedule and people stay out of it. There are only two ways to intervene: change the approach, or skip the step. The first is meaningless when the device simply has not received anything; the second produces the irreversible outcome described above. Inside the window, the only thing worth watching is whether the retry count and the next-retry time are moving.
Once the window passes with no receipt, the step moves from suspended to manual handling. The manual path has to be agreed while the workflow is being designed, not invented when the first unit appears: ship it back, send someone out, or wait until the unit returns to a site and clear it there. The cost and turnaround of the three options differ widely, and which one suits a given unit depends on its value and on how sensitive the residual data is.
A step finished manually has a receipt from a person, not from the device. Record the receipt source and the operator on the ticket. Without that, the ledger acquires a unit marked “wiped, no receipt”, and the next reconciliation treats it as an exception and investigates it again.
Take a fleet of 600 units retiring 45 units a month, where about 12 percent are unreachable at the moment retirement is initiated: 5 or 6 units a month land in the suspended queue. With a 7 days window and manual handling at about 1.5 hours per unit, that is about 9 hours a month, roughly 414 USD at 46 USD per hour. Leave the window unset instead and those units stay in the queue: they keep inflating the enrolled count, and at 10 minutes of reconciliation per unit per month the fleet spends 65 times 10 minutes a year, about 11 hours or roughly 506 USD, with each of those units sitting in a state where release has been considered but the wipe has not happened.
Retirement is complete only when all three agree. Checking the portal alone is the most common wrong verdict — it looks the most authoritative and in fact proves the narrowest thing.
What this gets wrong is the absence of any evidence. Without a receipt there is no basis for calling a step complete. Tickets of this kind share one signature: the serial number is gone from the portal while the management profile and the data are still on the unit, and nobody notices until that unit reaches the next customer.
What this gets wrong is that release is irreversible while failure is retryable. The test that separates them is exactly one thing: is there a receipt. A receipt means the step can be called success or failure; no receipt means suspended.
What this gets wrong is scope. Absence from the portal means the organisation no longer lists that unit; it does not mean the management profile was removed. Both can be untrue at once, and nothing raises an error.
Boundaries 1: manually enrolled units behave differently from automatically enrolled ones. On a unit enrolled manually that is still inside the 30-day window during which the user can remove management themselves, the outcome of the removal step is not decided by the server alone, and the suspension window needs adjusting accordingly.
Boundaries 2: where a unit has already been erased or has been unreachable for a long period, the remote wipe cannot be completed. The server can then do no more than release the serial number and archive the record; wiping waits for physical access. The endpoint of the workflow in that case is “discharged the duty and recorded it”, which is not the same as “all steps completed”, and the two must not be written as one.
Boundaries 3: this article covers how a retirement workflow is recorded, not the order of its five steps, and not how to read the four fields on a wipe verification receipt. The sequence and the receipt fields each have their own pages, as does what can still be locked while a unit is unreachable. This piece answers one question: when part of the workflow stalls, what state should it be recorded as, and which step must never run early.
It depends on the reachability profile of the fleet. The reporting cycle is about 24 hours and most temporary gaps close within 3 days; 7 days covers weekends and units in transit. Where units rarely leave a site, the window can be cut to 3 days — but check the historical distribution of how long suspended steps actually took to resolve before changing it.
Yes. It still occupies the enrolled count and still sits inside the management domain. That is one more reason suspension has to be closed out: left open, the enrolled count stays inflated and every reconciliation has to explain the extra units.
No. After release the unit is outside the management domain and the server has no channel to it, so “clear it when it comes back” is not an available path. Once it comes back, physical access is the only option.
Record two fields: receipt source, set to manual, and the operator. Do not leave the system default and do not leave it blank — a blank unit is treated as an exception at the next reconciliation and investigated again.
It depends on retirement volume. Fleets retiring more than 40 units a month should check daily whether retry counts are moving. Lower volumes can be checked weekly, but the transition to manual handling must trigger daily and must not be batched up.