A compliance issue on a dashboard is a number. Auto remediation turns it into work that finishes. A ticket opens, ONE takes it, and the straightforward cases close without anyone reading them — while the rest arrive at an admin with the investigation already done.
Overview
Three articles cover the configuration; this one covers the shape of the thing:
- Set up auto remediation — which statuses raise a ticket, the ticket defaults, and publishing
- Write your remediation policy — the mandate ONE works under
- What ONE does — the floor, the ceiling, and what your policy controls
How to use — the path from drift to closed
- A device checks in and its compliance is recomputed. Changing an MDM control triggers this too.
- A flagged status raises an issue, for anything set to Create Issue or Create Issue and Ticket.
- A ticket opens for the ticketed statuses, carrying a translated title, the Compliance tag, the device, its owner as requester, and your ticket defaults.
- ONE takes it — provided a policy is published. If none is, the ticket exists but stays with your team.
- ONE works it: reads the underlying issue and its evidence, refreshes the device, applies what it can apply, writes to the employee only when a human really is required, and posts its findings.
- Compliance returns and the ticket closes on its own. ONE does not close compliance tickets on its own initiative.
The vocabulary
| Term | Meaning |
| Compliance issue | A device presently reporting a status you flagged |
| Compliance ticket | The ticket opened for one issue. Never more than one per issue |
| Remediation policy | The written mandate. Publishing it is the on switch |
| Auto remediation: ON / OFF | The chip on the settings page. ON only while a policy is published |
Three things that are dependable by design
- Nothing is lost to a bad moment. Ticket creation and closure are reconciled at every compliance computation, so an outage costs you a sync cycle, not a ticket.
- Enabling ticketing catches up on history. Flip a status to Create Issue and Ticket and tickets appear for devices already in that state, not just future ones.
- You are never locked out of the manual path. Any single row in the issues list can be ticketed by hand, including statuses you deliberately left unticketed.
Permissions
| Action | Permission |
| View issues, settings and policy | MDM_READ |
| Change settings, edit and publish the policy | MDM_WRITE |
Tips and best practices
- Publish last. Everything else is preparation; publishing is the moment it starts happening.
- Expect the backfill and plan around it. The first ticketed status catches up on your whole fleet at once.
- Ticket much less than you flag. Flagging costs nothing; a ticket is a promise that it gets worked.
- Judge a run by its note, not by whether the issue closed. A well-diagnosed hand-back is a good outcome.
Troubleshooting and FAQ
Troubleshooting
- Tickets are appearing but nothing is working them. No published policy, so they open unassigned to ONE.
Check the chip. - A ticketed status produced no ticket for a device.
Look for an exception covering it — unassigned and in-stock devices are skipped completely — or a grace period still running. - One device has five tickets.
By design. One ticket per issue, five issues, five tickets.
FAQ
-
What turns this on?
Publishing the remediation policy. Only that.
-
Do tickets open without a policy?
Yes, they just are not handed to ONE.
-
Will it ever close a ticket by itself?
Not on its own initiative. Closure comes from the device becoming compliant, or from an admin instructing it.