Published 2026-10-19 · LuckyMDM Blog
The bottom line: whether a managed device can report a given field has nothing to do with whether it is enrolled. It depends on three separate questions — does the device produce that value itself, has anyone actually asked for it, and does this unit meet the precondition that field requires. Enrolment only buys you the right to send commands and have them obeyed. It does not buy you a data feed.
This is the single most common source of confusion in a device fleet, and it is expensive in a quiet way. A column that looks empty reads as "the system is broken" or, worse, as "there is nothing to see here". Usually neither is true. Nobody asked.
Enrolment establishes trust. The device accepts that this organisation may configure it, and it will execute what arrives over that channel. What enrolment does not do is populate a database on your side. That requires a separate motion: something has to request a value, the device has to answer, and the answer has to be written down.
Open a device record and look at a blank column. The usual reflex is to blame synchronisation. The more frequent explanation is that no request was ever made for that particular value, or a request was made while the device was offline, or the device does not meet the precondition for answering.
There is a cheap way to tell the two apart: look for a collection timestamp attached to that column specifically.
When one "last updated" timestamp covers the whole row, these two states collapse into one and can no longer be distinguished. That is how a fleet ends up trusting a value that was never collected.
From the device to the table on your screen, the value passes through three stages:
The underlying model is command and receipt, not database replication. In replication, data exists at the source and eventually appears at the destination. In a command model, if nobody asks, the value never exists at all. That distinction explains almost every "missing field" ticket in a fleet of any size.
Systems such as LuckyMDM (Sichuan Starlight Network LLC) treat that distinction as a design requirement rather than a reporting nicety: a field is shown as holding a value only when a request produced a receipt for it, and the receipt carries both the collection time and the source request behind it.
Sort every column in your device register by where the value comes from, and most of the confusion resolves itself. The three sources differ in how they are triggered, how fresh they are, and how they fail.
| Source | How it is triggered | Typical fields | Freshness behaviour |
|---|---|---|---|
| Check-in | Device reports on a fixed interval with no human action | Last check-in time, OS version, device name, available capacity | Refreshed once per interval; the interval sets the upper bound on detection lag |
| Query | Requires an explicit request; the receipt carries the value | Installed application list, security posture, profile list, detailed hardware information | One receipt equals one snapshot; no re-request, no update |
| Payload state | Exists only because a configuration payload was delivered | Whether a specific restriction is in force, whether a profile installed successfully | Changes with configuration; removing the payload removes the state |
These are the easiest and the most often over-read. The device clocks in on schedule, the server records the moment it arrived, and a handful of fields come along with it. The weakness is not collection but interpretation. A check-in proves the device was reachable at that moment. It does not prove it is reachable now. Set the interval to 15 minutes and the upper bound on detection lag is 15 minutes. Set it to 4 hours and the bound is 4 hours, no matter how the dashboard renders it.
This is where most empty columns originate. A query request carries a list of fields. The device answers that list. Anything not on it does not come back "just in case". Request 3 fields and the receipt contains those 3 plus a small fixed set. Want a fourth next month, and you send another request.
That mechanism explains a pattern that otherwise looks like hardware variance: two units from the same purchase order, configured the same way, with very different field coverage. The devices are not different. The history of questions asked of them is.
"Has this restriction taken effect" is not a physical quantity waiting to be sampled. It is a derived answer that only exists if the restriction was delivered in the first place. Without delivery, the field is not blank — it is absent.
The trap here is that removing a payload does not clear the last reported state. Left unmanaged, the register keeps a conclusion that was true months ago, and the device has not carried that configuration for a long time.
Identical field name, different coverage. This is the layer that is hardest to infer from a dashboard, and it explains a large share of "the query works but the data is thin".
A managed device can be asked what is installed. What comes back depends on supervision. On a supervised device you can obtain the complete list. On an unsupervised device, the return is typically limited to applications installed or managed by the management side. Apps the user installed from the store are outside that scope.
So the same request produces counts that differ by an order of magnitude across two units sitting in the same rack. Before concluding that the query failed, confirm the supervision state. In practice, sampling five units and checking supervision first will explain the gap faster than re-running the query will.
On units that do not meet the precondition, restriction-type configuration is frequently ignored rather than refused. The delivery reports success, the console lists the setting as configured, and nothing changes on the device.
This class of silent non-application is more dangerous than an error, because errors get investigated and successes do not. The check has to happen on the device side: open your settings, go to General, then VPN and Device Management, and confirm the profile is present. Then confirm the feature the restriction targets is actually blocked. Configured on the server and unchanged on the device is precisely this failure.
A receipt is the device's answer at a moment in time. Written to the register, it is a record with a timestamp. Everything that happens afterwards on the device is invisible to that record. A user removes an app, a toggle gets switched off, an OS update lands — the stored value does not move.
This is why a per-field collection time is not optional. A field without one can only establish "this was true once". With one, even a stale value is useful, because you know exactly how stale it is and can decide whether that is acceptable for the decision at hand.
The same field can arrive by different routes. Application inventory might come from a routine query, or from a one-off audit. The two have different scope, different reliability, and different timestamps. Store only the value and you lose the ability to answer which request produced it — and therefore whether it can support the decision you are about to make with it.
Gaps do not disappear. They move. Take a fleet of 500 devices and three items that only query-type fields can supply: installed applications, security posture, and the profile list.
The hours are the visible cost. The larger cost is behavioural: when a value cannot be seen, people substitute an assumption for it — assume nothing is installed, assume the profile is clean, assume the record is current. Assumptions are cheap until the moment an assumption is the only thing standing between you and a disputed return, and by then the collection window has closed.
Pull three fields and see whether each carries an independent collection timestamp. If all three share one "last updated" value, the system records row-level refresh only, and you cannot tell which field is current.
Request 3 fields, then count what comes back. More than expected means the field list did not take. Fewer means one item was refused — and that item is usually the one whose precondition is unmet.
Pick two devices, one in each state, and send the same application inventory query. A large gap in returned counts means coverage depends on supervision, and any reporting built on that field has to be split by state rather than averaged.
Take any restriction, read its status on the server, then open your settings on the device and check General, then VPN and Device Management, for the profile. When the two disagree, the payload landed on a unit that does not meet its precondition.
This confuses authority with a data channel. Enrolment grants the right to act. A field is a collection result, and between the two sit the questions of whether anyone asked and whether the device answers.
This treats a snapshot as a subscription. The receipt describes one moment. Its value depends on when it was collected, not on the fact that it was collected at all.
Far more often the field was never on the request list, the unit is unsupervised, or the payload was never delivered. Rule out those three before concluding a capability gap.
Boundary 1: not every field is readable. Account-level information — which account is signed in, what it is linked to — sits outside what a device can be asked to reveal. What you can usually obtain is a state flag such as whether a session is signed out. Treating an unreadable field as readable builds risk logic on data that will never arrive.
Boundary 2: field names and readable ranges are platform-bound. The field names and preconditions here describe iOS devices. On Android the naming, the readable scope, and the preconditions vary by manufacturer and by management approach. A single cross-platform definition has to be verified separately on each side before it is used to compute anything.
Almost always because the history of collection differs. Some units were individually queried; others only ever sent check-ins. Coverage reflects what was asked, not how good the hardware is.
They answer different questions. For "is it still there", use check-in, which carries the server's receipt time. For "what is inside it", only a query helps. Substituting one for the other produces confident wrong answers.
Start with supervision, because restriction payloads can be silently ignored on units that lack it. Then confirm the profile exists in the device's profile list. Only when both line up is the configuration real.
Yes. A single row-level timestamp cannot answer when a particular field became what it is. Per-field collection time is the only way to separate an empty value from an unread one.
No. Split by use: fields that feed a decision or a calculation get re-collected on a schedule; fields that are display-only can be left alone. The test is whether a stale value could cause a wrong decision. If it could, the field needs a timestamp and a refresh cadence.
LuckyMDM is built on this distinction: the device record marks each field with the collection time and the source request that produced it, and shows never-collected fields as never collected rather than as empty values. That convention is not specific to one vendor — any fleet that makes decisions from a device register needs the same separation between an empty answer and an unasked question.