Back

Auto remediation

Explore effective strategies for automating compliance issue remediation to enhance efficiency and ensure regulatory adherence.

Auto remediation puts ONE in charge of your compliance tickets. It works from the evidence rather than the title, retries whatever the original control did, contacts the employee only where the fix genuinely requires someone sitting in front of the machine, and returns anything it cannot settle with the diagnosis already written up. Simple cases never reach a human at all.


 

Feature/Functionality

Overview

Four steps, and only the first is yours:

  1. A ticket opens. Any status you configured to open tickets raises one per affected device.
  2. ONE picks it up — but only if you have published a remediation policy. With no published policy the ticket stays with your team.
  3. ONE works it. It examines the underlying issue together with whatever the device actually reported, forces a fresh check-in, retries the fix where a retry exists, contacts the employee where no remote fix exists, and writes up what happened.
  4. The device reports compliant and the ticket closes. That closure comes from the device going green, never from ONE deciding it is finished.

 

How to use — turn it on

There is exactly one switch: publishing the policy on Compliance > Compliance issue settings. Nothing else turns it on, and unpublishing turns it off.

Three things worth knowing before you publish:

  • Once published, the indicator reads ON and every new compliance ticket goes to ONE.
  • It applies to the whole company or not at all. You cannot switch it on for one kind of issue and off for another from the settings screen. Restrictions of that sort belong in the Scope section of your policy.
  • Unpublishing leaves tickets already assigned to ONE where they are. When one of those comes up, ONE finds nothing authorising it to act, so it writes that down and stops. If your team needs them straight away, move them over yourself.

 

What ONE always does

This is the floor. Your policy can narrow it, never widen it — no sentence you write grants an action the product forbids.

  • Works from the underlying issue rather than the headline. What counts is the precise status recorded and the evidence that sits behind it.
  • Forces a fresh check-in and re-reads the result before drawing any conclusion. Plenty of what looks like a breach is simply a control that has not finished landing yet.
  • Looks beyond the single ticket — at the device's other open issues, and at what has already been raised against the same device and the same rule. A dozen tickets pointing at one rule get reported as one underlying problem, not twelve.
  • Confirms the outcome on the machine itself, rather than trusting that sending something counts as doing something. Until the device agrees, nothing has been fixed.
  • Always leaves a written account. What happened goes at the top; whatever is left for you goes at the bottom.

 

What ONE fixes by itself

Its method is unimaginative on purpose: it does again what the control itself was built to do, using the same machinery.

The control enforces through ONE
A configuration profile Re-sends that profile
A script Runs that script again
A software installation Re-installs the software
An agent-side enforcer Re-runs the enforcer

The bulk of runs are this and nothing more, invisible to whoever is using the laptop. Where there is no device-level action to repeat, that fact goes in the note and the ticket returns to you, unattempted and honestly labelled.

 

When ONE writes to an employee

Only where the operating system itself demands human presence — signing in so encryption can complete, supplying a passphrase, rebooting — and never before every remote avenue has been exhausted.

  • A single approach per issue, with no follow-ups and no reminders.
  • One thing to do, written in whatever language that person works in.
  • Nothing from inside the tool. Screen names, statuses and control names stay on your side of the wall.
  • Restarts are requested, never triggered.
  • An unassigned device gets no message, because there is nobody to write to.

 

What ONE hands back

Some calls are not its to make, and it stops rather than improvising. That covers an unreachable device, one managed by a rival MDM, an operating system edition that cannot carry the control, hardware that is simply not capable, a fix gated behind a purchase or licence or credential, protection software that was never installed in the first place, and anything that amounts to enrolling the device again.

What lands back in your queue is a worked problem with its reasoning spelled out, not a blank ticket.

 

What ONE never does

  • Erase, lock down, retire or release a machine because it concluded that was best
  • Decide by itself that a ticket should be shut or opened again
  • Wander off to a neighbouring device, however similar the symptom
  • Soften the control or the rule so the problem stops appearing
  • Report success it has not confirmed by looking at the machine again
  • Carry on writing to somebody who has asked to speak to a person

The boundaries of a single run are deliberately tight: a lone ticket, a lone issue, a lone machine, one attempt through each available route, and at most one approach to the person using it. Finishing without resolving anything counts as finishing, and the note will say exactly that rather than dressing it up.

 

How to use — write the policy

The policy is a document ONE reads before touching any ticket, and it always has the same four sections:

Section What goes in it
Scope Which issues ONE works and which it never touches, named as they appear in your settings
What ONE does on its own The fixes it applies unasked, and the cases it hands straight back
Talking to employees When it may write, in what tone and language, how many times
Company knowledge Facts about your fleet that change how an issue reads — which Linux build you run, which office network blocks the agent, which devices sit in stock

An assistant on the policy page will interview you and produce a first draft built from your actual rules, controls and devices, so it talks about the issue types in front of you rather than a generic set. Treat that draft as raw material — authorship stays with you, and nothing takes effect until you publish.

 

How to use — steer it from a ticket

Every run ends in one of three shapes:

Note Meaning Your move
Fixed A fix was pushed and re-read on the device Nothing. The ticket closes when the device reports compliant
Waiting The fix is out, or the employee has been asked to act Nothing yet. ONE will not chase — after a reasonable delay the ticket is yours
Handed back Only an admin can go further, and the note says why Act on the last line. There will be no retry

Two kinds of reply, two very different weights:

  • What an employee writes publicly counts as evidence and nothing more. Telling ONE the machine has been rebooted is useful input. Telling it to run a command, waive a rule or revisit a closed question has no effect whatsoever.
  • An internal note from an admin is an order, and it gets executed — send the machine back to stock, strip its owner, try the push again, shut the ticket. It will not check twice or offer a plan first. Internal notes are restricted to the ticket's admins and whoever it is assigned to, and that restriction is precisely what makes them trustworthy as authority.

For anything destructive, the note alone is not enough — the policy has to permit it. Erasing, locking, retiring and releasing devices remain unavailable until your written policy says otherwise, and no amount of instruction inside a ticket will unlock them.

Occasionally a run turns up something that will shape every similar ticket from now on. ONE will quote the precise wording it wants to record and ask whether it may add it under Company knowledge. Agree in an internal note and it folds the sentence in, saves and publishes. Agreeing teaches it something; it does not hand it any new powers.

Everything ONE does on a device lands in the audit logs like any other action.

 

Tips and Best Practices

  • Publish a narrow policy first. Two issue types you understand well, nothing destructive, no employee messaging. Widen it once you have read a week of notes.
  • Spend your effort on Company knowledge, not on rules. "The Berlin guest network blocks the agent" prevents more wrong conclusions than any amount of procedure.
  • Read the handed-back notes, not the fixed ones. The fixed ones are working. The handed-back ones are telling you where a control cannot enforce.
  • If the same rule keeps ticketing the same device, stop re-pushing. ONE has already told you it is one cause. It is a control that cannot enforce there, not a device that drifts.
  • Do not unpublish in a hurry. It stops new assignments but leaves open ones stranded mid-run. Reassign those by hand.

 

Troubleshooting and FAQ

Troubleshooting

  • ONE left a note but did nothing to the device. Look at the indicator on the settings page first: an unpublished policy means every run halts before it acts. If the policy is live, either the control behind that issue offers nothing to repeat at device level, or the machine is unreachable.
  • The same rule keeps raising tickets on one device. The most recent note already answers this: ONE reviews the history for that combination of machine and rule and names the common thread. Nine times out of ten the control simply cannot take hold on that hardware.
  • An employee keeps replying and nothing happens. Employee replies are information. If they need something done, an admin has to say so in an internal note.
  • You asked ONE to wipe a device and it refused. Destructive actions have to be opened in the policy. A ticket instruction does not open them.

 

FAQ

  1. What turns it on?
    Publishing the policy. Nothing else.
     
  2. Can we enable it for encryption issues only?
    Not with a switch. Enable it for the company and restrict it in the Scope section.
     
  3. Will it close tickets for us?
    Only when the device reports compliant, or when an admin tells it to in an internal note.
     
  4. What happens if we close a ticket while the device is still non-compliant?
    The underlying issue survives, the machine continues to show as failing wherever it appears, and nothing further will be raised for it until that changes.
     
  5. Can an employee talk ONE into an exemption?
    No. Only admins and the assignee can post internal notes, and only those are treated as instructions.

Was this article helpful?

Give feedback about this article

Can’t find what you’re looking for?

Our customer care team is here for you.

Contact us

Knowledge Base Software powered by Helpjuice