The policy is a Markdown document that ONE reads before touching anything. It is the difference between a ticket sitting in a queue and a ticket being worked — publishing it is what switches auto remediation on.
One thing to understand before you write a word: a policy can only take things away. No sentence in it grants an action the product does not already allow.
Overview
You do not start from a blank page. The policy page has a chat that interviews you and drafts it, and it drafts against your real configuration — your issue types, your controls, your fleet — so the result names things you actually have instead of a generic example.
How to use
- Open Compliance > Compliance issue settings and go to the remediation policy
- Answer the interview. Which issues you want worked, how far ONE should go alone, and how it should speak to employees.
- Edit the draft. It wrote it; you own it. Change anything.
- Publish. The chip flips to Auto remediation: ON.
What goes in each of the four sections
- Scope. Which issues are in and, more usefully, which are out. Write exclusions by the exact name they carry in your settings — it is far easier to list the handful of things ONE must never touch than to enumerate everything it may.
- What ONE does on its own. The repairs it should attempt unprompted, and the situations it should escalate without trying. Think in terms of when you would rather have a diagnosis than an attempt.
- Talking to employees. The circumstances that justify contacting someone, the language and register, and the volume. One message per issue is the default — say so here if you want it tighter, or if certain people should never be written to at all.
- Company knowledge. The facts about your estate that change how an issue should be interpreted: which distributions you actually run, which site has a network that blocks the agent, which naming convention marks stock. This section grows over time — ONE proposes additions and you approve them.
A policy to start from
Replace every line of this with your own reality:
```markdown
Scope
- Work encryption, OS update, EDR, admin account and profile delivery issues on macOS and Windows laptops.
- Never work issues on devices in the Warehouse device group — those are held in stock and are expected to be offline and unencrypted.
- Never work iCloud lock issues. Route them to IT untouched.
What ONE does on its own
Re-push configuration profiles, re-run control scripts, and re-install missing software without asking.
Hand back to IT, without attempting a fix:
- any device offline for more than 7 days
- any issue on a device that already had 3 tickets on the same rule
- anything needing a purchase, a licence, or a re-enrolment
Talking to employees
- Write to the employee only when the operating system needs them at the keyboard, and only once everything remote has been tried.
- One message per issue. Write in the employee's language. Never name an internal control or screen.
- Never write to employees in the Executive team — raise those to IT instead.
Company knowledge
- Our Linux fleet is Ubuntu 22.04 LTS only.
- The Berlin office guest network blocks the agent; devices there sync over VPN only.
- Devices named STOCK-* are held in stock and have no assigned employee.
Living with it
- The draft and the published version are separate: editing changes nothing until you publish.
- Unpublishing stops new tickets going to ONE, but leaves it on the ones it already has — those stop with a note instead of acting.
- When ONE proposes a fact for Company knowledge and you approve it, the edit is attributed to ONE and its note records which admin approved it. If your draft has unfinished edits at that moment, it saves the addition without publishing and tells you.
Tips and best practices
- Write Scope as exclusions. Listing what to avoid is shorter, clearer and ages better than listing what to permit.
- Fill Company knowledge on day one, before the first ticket. The site with the blocking network will otherwise generate a stream of tickets that all look like drifting devices.
- Keep one message per issue unless you have a real reason. Chasing is how a helpful tool becomes one people mute.
- Use the interview once, then edit the text. Re-interviewing for small changes is slower than editing four sections.
Troubleshooting and FAQ
Troubleshooting
-
The assistant cannot see your rules, or publishing does not flip the chip.
Write to support@factorial.it with your company name, when you published, and a screenshot of the chip. -
A knowledge addition saved but the policy did not publish.
You have unfinished draft edits. Finish or discard them, then publish. -
A sentence appears to be ignored.
It is trying to grant something. Policies narrow only, so a permission-granting sentence has no effect.
FAQ
-
Do we have to use the assistant?
No. It produces a first draft; the document is yours to rewrite entirely.
-
Can the policy authorise a wipe?
Destructive actions stay closed unless the policy opens them explicitly — and a ticket instruction never opens them by itself.
-
What if we never publish?
Compliance tickets still open. They just stay with your team.