Published 2026-10-18 · LuckyMDM Blog
The bottom line: a policy group does not decide what a set of devices is called. It decides who receives the next command. Put storefront demo units and subscribed units in the same group and a single bulk lock reaches the demo units too - and the command runs against the membership snapshot taken when it was submitted, which is not always the membership you were looking at a minute earlier.
LuckyMDM (Sichuan Starlight Network LLC) builds group handling around that distinction, and the rest of this article explains why it matters and what to check before pushing anything in bulk.
Some fields are descriptive: model, capacity, cosmetic grade, purchase batch. Get one of those wrong and searching is annoying. Others are behavioural: which policy group this unit sits in. Get one of those wrong and the unit starts receiving commands it was never meant to receive. Group membership is the second kind. Its job is not faster filtering - it is drawing a perimeter around every downstream action.
The path a bulk command takes is fixed: pick a group, expand it into a device list, deliver to each unit. The expansion happens server-side. Once the list exists, nothing goes back and asks whether each unit on it should actually be receiving this command. That is why the underlying mechanism makes a grouping mistake hard to walk back - the command has already landed, and reversing it means pushing another command and waiting for the unit to come online.
The reason a push can reach a slightly different set than the one on screen is that these two things do not share a lock: someone edits membership on one track, a command is submitted on another. If a unit is moved into the group between expansion and delivery, it receives the command anyway. The larger the group, the more often that window gets hit.
| Grouping mistake | Triggering action | Immediate result | Recovery path |
|---|---|---|---|
| Demo units and subscribed units together | Bulk lock | Showroom handsets locked, nothing to demonstrate | On-site unlock per unit, 30 minutes each |
| Units pending inspection together with live units | Bulk configuration push | Unaccepted units reconfigured, baseline lost | Erase and re-enrol, about 40 minutes each |
| Settled-but-not-released units together with live units | Bulk lock or erase | Control action applied where obligations are already met | Unlock on site plus a written note; complaint cost is separate |
The third is the one that carries real weight. The first two are internal efficiency losses. The third concerns a device whose obligations are already discharged - the justification for a control action comes from an agreement that is still open, and once it is closed, continuing to enforce changes the character of the act. That is why the first split in most fleets is not model or store, but which stage of the agreement the unit is in.
Do not press send. Expand the target group into a device list first and read the usage field on every row. Two minutes of this catches nearly every mixed group. The rule is that a single row with the wrong usage stops the push - you fix the group first rather than sending and cleaning up after.
Correct grouping does not help if the members are offline. The command queues, the console shows delivered, and nothing has happened on the device. So after expanding, look at this field: any unit whose last check-in is older than one check-in interval will not act in this pass and needs its own window, not repeated resends.
Pilot before committing to the full batch. Size the wait by the check-in interval rather than by clock time - common intervals run from 15 minutes to 4 hours, so take the upper bound as the pilot window. Watch two things during the pilot: whether the targets changed as intended, and whether anything outside the target set changed at all.
The reporting dimension decides whether you can see the problem. Reporting by command tells you 986 succeeded and 14 failed. Reporting by group tells you all 6 demo units succeeded - and that second sentence is the one someone needs to read. The acknowledgement table therefore carries a group column, not just a command column.
Take a fleet of 1,000 units with 6 storefront demo units sitting in the same group as live subscription units. After one bulk lock: unlocking those 6 units on site takes 30 minutes each, or 3 hours, roughly 108 USD at 36 USD an hour; the store is out of action for 2 hours with 2 staff involved, 2 hours times 2 people times 36 USD an hour, or 144 USD. That is about 252 USD, before counting the walk-in experience.
On the other side, splitting demo units into their own group is a one-off configuration of about 25 minutes, roughly 15 USD. The ratio is around 17 times. The asymmetry is that configuration is paid once, while a mixed group can be paid for again on every push.
Filtering is for people; grouping is for commands. When grouping is built as a filtering tool, the result is usually a group per model, a group per store and a group per batch, with each unit in several at once. Once groups overlap, the blast radius of a command becomes a union or an intersection depending on implementation, and nobody on the floor can predict which. Fewer dimensions is better, and usage is the one worth keeping.
Delivery is one-way. There is no stage where you retrieve the units that should not have received it. Reversal needs the unit online, needs a second command, and needs that command to be received - miss any of the three and recovery slips to the next time the unit checks in. The window in which a push is reversible closes when it is submitted, not when someone notices.
Group membership shrinks for two different reasons: the unit was released, or someone moved it to another group. Both look identical in the group list and mean opposite things. The way to tell is the enrolment field on the device register - enrolment unchanged while the group changed means a move, not a release.
If nothing is ever pushed in bulk, the boundary function of a group fades and only the filtering value remains. Two or three groups by usage is enough; time spent on group governance is better spent verifying enrolment state.
Some policies support conditions inside the rule itself rather than relying on a group to define scope. That replaces part of what a group does, but not all of it - conditions answer "what must be true for this to run", while a group answers "who can this reach at most". Where both exist, the result is the intersection; where only one can be kept, keep the group, because its blast radius is easier to read.
LuckyMDM separates policy groups by device usage, keeps demo units and subscribed units in non-overlapping groups, and delivers commands per group.
Operators running device subscription fleets generally treat a group change as something that needs a second pair of eyes, for one reason: it edits not a description of one device, but what a whole group of devices will receive next.
Which dimension should groups be built on?
Usage first, agreement stage second. Model, store and batch belong in filters rather than groups, because they do not decide what a unit should receive. Once the number of dimensions passes two, group count multiplies and governance costs more than the convenience returns.
It can, but be clear about how overlap resolves. With a usage group and a store group both present, a command targeting both resolves to the intersection, while one targeting either resolves to the full set. Teams that cannot state which applies should keep one usage group per unit and move the rest to filters.
Which 10 units belong in a pilot?
Not the 10 most convenient ones. Pick across states: some online, some with a stale last check-in, some recently restarted. A pilot exists to expose differences, and ten units in identical states carry almost no information.
Three steps, in order: stop the remaining batches, push the reverse command to the units already affected, then record the grouping error in the change log. The order matters - reversing before stopping lets a new batch add more units to the affected set.
Event triggers work better than a calendar. New site, new device usage, a failed bulk command, or any membership change should each trigger a review. With no events, a quarterly check that membership matches the register is enough.