Every boundary here is deliberate. Knowing them lets you tell "this is how it works" from "something is broken" — which is usually the difference between a policy edit and a support ticket.
Overview
Four constraints shape how you configure everything else.
- Scoping lives in prose, not in toggles. There is no per-issue-type switch for ONE: it is on for the company or off for the company. Which issues it leaves alone is something you write in the Scope section of your policy, by name.
- Unpublishing is not an emergency stop. It stops new tickets being assigned, but tickets already with ONE stay with ONE — they simply read the missing mandate and stop, with a note. If you need your team on them today, reassign them by hand.
- Tickets follow issues one-for-one. Five issues on a device means five tickets. That is the design, not duplication.
- Policies subtract, never add. A sentence granting something the product forbids has no effect at all.
How a fix is re-applied
ONE does not invent a repair. It repeats whatever the control did in the first place:
| The control enforces through | ONE repeats it by |
| A configuration profile | Re-sending that profile |
| A script | Running that script again |
| A software installation | Re-installing it |
| An agent-side enforcer | Re-running the enforcer |
That covers the majority of compliance issues. What makes it trustworthy is the step after: it re-reads the device. A push that went out successfully proves nothing on its own.
Where a control has no per-device mechanism to repeat, it says so and hands the ticket over rather than performing activity that changes nothing.
The six reasons a ticket reaches you anyway
When a ticket comes back, it is nearly always one of these — and the note names which:
- The device is offline, so nothing can be pushed or verified
- The device is enrolled in another MDM, where we observe but do not enforce
- The OS edition cannot be managed for that particular control
- The fix needs a purchase, licence or credential we do not hold
- The EDR was never deployed, so there is nothing to repair
- The device needs a re-enrolment, which is your call
Attribution
Everything is traceable. Device actions land in the audit logs like any other action. A policy change made on your approval is recorded as ONE's change, and the note names the admin who approved it.
Demo companies
A demo company runs the genuine flow against fabricated device data, and the assistant is live — commenting on a demo compliance ticket starts a real run. Changes to compliance settings and to the policy are blocked there.
Tips and best practices
- Stop looking for the toggle. Scoping is prose in the policy; there is no per-type switch and there is not going to be one in the UI you are searching.
- If you unpublish in a hurry, reassign the open tickets too. Otherwise they sit with ONE doing nothing and nobody notices.
- Check the six reasons before escalating a handed-back ticket. The note already tells you which one it is.
- Use a demo company to rehearse, but remember comments there trigger real runs.
Troubleshooting and FAQ
Troubleshooting
-
You want it working encryption but not OS updates.
Write that in Scope. No toggle exists for it.
-
You unpublished and it is still assigned to tickets.
Working as designed — it stops acting but stays assigned. Reassign them.
-
A ticket says there is nothing to repeat.
That control has no per-device mechanism to re-apply. It is a product limit, and the fix needs a person.
-
A policy sentence is doing nothing.
It is trying to widen permissions. Policies only narrow.
FAQ
-
Can we turn it on for one issue type only?
Not with a setting. Name your exclusions in the Scope section instead.
-
How does it decide what to try?
It mirrors the control's own mechanism, then confirms by re-reading the device.
-
Is everything auditable?
Yes — device actions in the audit logs, and policy changes naming the approving admin.