ONE works inside a hard boundary that your policy cannot move outward. This article draws that boundary: the floor of what it always does, the ceiling of what it never does, and the middle ground your policy actually controls.
Overview
Read this before writing a policy. Knowing where the floor and ceiling sit tells you which of your sentences will do something and which are already guaranteed — or already impossible.
The floor: six things it does on every single run
None of these are optional and none can be switched off.
- It goes to the issue, not the title. The ticket title is a label; the decision comes from the exact status and the evidence the device reported.
- It checks your mandate. No published policy means no action at all, on anything.
- It re-reads the device before concluding. This one matters more than it sounds: a large share of "non-compliant" devices are settings still on their way, not devices that drifted.
- It looks past the single ticket — at the device's other open issues, and at what happened on this device and this rule before. Twelve tickets sharing a cause get reported as one cause.
- It confirms on the device, not on its own dispatch. A push that was accepted is not a fix until the device says so.
- It writes a note. First line: what happened. Last line: the one thing left for you.
The middle: what it can actually do
Re-applying the fix. Whatever the control used originally — a profile, a script, a software install, an agent enforcer — it repeats that same mechanism. Most runs are nothing but this, and nobody outside IT notices.
Writing to the employee, but only under real constraints. It writes when the operating system needs a human present and nothing remote is left to try. Then: one message, one instruction, the employee's language, no internal terminology, and never again for that issue. It asks for a restart; it does not perform one. A device with no assigned employee gets no message at all.
The ceiling: where it stops
Two different kinds of stop, and it is worth telling them apart.
Stops because only you can decide — the ticket comes back with the diagnosis already done:
| Situation | Why it needs you |
| Unmanageable OS edition | Nothing to push |
| Hardware below what the fix needs | Nothing to push |
| Needs a purchase, licence or credential | Not ONE's to spend or hold |
| Needs a re-enrolment | An admin decision |
| EDR never deployed | Nothing to repair |
| Offline, or enrolled elsewhere | Out of reach |
Stops because it is forbidden — no policy sentence opens these on its own reading:
- Wiping, locking, retiring or unenrolling a device
- Closing or reopening a ticket on its own initiative
- Touching a second device, however similar
- Editing the control or the rule so the issue disappears
- Reporting a fix it has not confirmed on the device
- Continuing to write to someone who asked for a human
One run, one scope: One ticket. One issue. One device. One attempt per mechanism. One message.
A run that ends with the issue still open is a correct outcome, not a failure — and the note says so rather than dressing it up.
Tips and best practices
- Read the ceiling before you write your policy. Most of what people want to forbid is already forbidden, and the rest cannot be granted.
- Treat a handed-back ticket as finished work. The diagnosis is the deliverable; the decision was always going to be yours.
- When one rule floods you, open one ticket and read its note. It has already correlated them, and the answer is usually a control that cannot enforce on those devices.
- Plan your own follow-up for employee messages. One per issue is deliberate — nobody is chasing after that.
Troubleshooting and FAQ
Troubleshooting
-
A note appeared but the device was untouched.
Work through three causes in order: no published policy, a control with nothing repeatable per device, or a device that is offline. It hands offline devices back rather than queueing work at them. -
Tickets keep reappearing on the same device and rule.
Read the most recent note — it correlates them and names the shared cause, which is nearly always a control that cannot enforce there. -
An employee answered and nothing moved.
Employee replies carry information, never instructions. Only an admin's internal note directs it.
FAQ
-
Can a policy let it wipe a device?
Only if the policy explicitly opens destructive actions. Its own reading of a ticket never opens them.
-
Will it keep reminding an employee?
No — one message per issue, and it stops completely if someone asks for a human.
-
How does it know a fix worked?
It re-reads the device. A successful push on its side does not count.