Everything lives on one page — Compliance > Compliance issue settings — and the order you touch it in matters. Decide what deserves a ticket, decide what those tickets look like, and only then publish the policy that hands them to ONE.
Overview
Publishing is the switch, which is why it comes last. Do it first and you will be editing defaults on tickets that already exist.
For what ONE actually does with a ticket once it has one, see What ONE does on a compliance ticket.
How to use — step one, decide what deserves a ticket
- Set the statuses you want worked to Create Issue and Ticket.
- Resist the temptation to ticket everything you flag. Raising an issue is free visibility; opening a ticket is a commitment that someone — a person or ONE — will work it. Most teams flag widely and ticket narrowly, and the ones who do the opposite end up ignoring their own queue.
- The first time you do this, tickets appear for devices already in that state. That backfill is intentional. On a fleet with real drift it can be a lot of tickets at once, which is a good reason to do it when you are watching.
How to use — step two, decide what the tickets look like:
Three defaults apply to every ticket opened from a compliance issue:
- Default assignee — though ONE takes over while your policy is published
- Default priority
- Default subscribers
None of them are locked: your team can change any of them on an individual ticket afterwards. But they are inherited at creation, so the backfill uses whatever they say at that moment.
How to use — step three, publish:
- The policy carries a draft and a published version, and only publishing has any effect on behaviour.
- Publish and auto remediation is on. The state chip reads Auto remediation: ON and every new compliance ticket goes to ONE.
- Do not publish and tickets still get created — they simply stay in your team's queue, like any other ticket.
Unpublish and new tickets stop going to ONE. What it does not do is take ONE off the tickets it already holds. Those runs find no mandate and stop with a note. Move them by hand if you want your team working them today.
Permissions
| Action | Permission |
| View settings and policy | MDM_READ |
| Change statuses, defaults, edit or publish the policy | MDM_WRITE |
Demo companies block write actions, and ship with a published policy and open tickets so the flow is visible.
Tips and best practices
- Get the ticket defaults right before publishing. The backfill inherits them, and correcting a hundred tickets afterwards is a bad afternoon.
- Publish when someone is watching, not at 18:00 on a Friday. The first backfill is the noisiest moment this feature has.
- Trust the state chip over everything else. If it does not say ON, nothing is being worked, whatever else you configured.
- Do not treat unpublishing as a kill switch. It only stops new assignments.
Troubleshooting and FAQ
Troubleshooting
- A status is configured but no tickets appear.
Check three things, in this order: is the device covered by an exception (unassigned, or in stock)? Is a grace period still counting? Is the status really on Create Issue and Ticket rather than Create Issue? If none of those explain it, write to support@factorial.it with your company name, the issue type and status, a device that should have raised a ticket, and whether that device is unassigned or in stock. - The chip reads OFF after publishing.
Re-open the policy — unfinished draft edits can leave the published version behind. - New tickets are not reaching ONE.
No published policy. They open as ordinary tickets.
FAQ
-
What order should we do this in?
Statuses, then defaults, then publish. The policy is the switch and belongs last.
-
What happens to open tickets when we unpublish?
They stay with ONE, which stops acting. Reassign them yourself.
-
Can we rehearse this safely?
Yes, on a demo company — real flow, fabricated device data, settings locked.