Skip to main content
Once a compliance ticket is assigned to Primo AI, it works within the mandate of your remediation policy. This article describes the behaviour the product guarantees, whatever your policy says — your policy can narrow it, never widen it.

​
What it always does

  • Reads the issue behind the ticket first. It never works from the ticket title. It reads the exact status and the raw evidence the device reported.
  • Reads your policy. With no published policy it acts on nothing.
  • Refreshes the device and re-reads its state before concluding. A large share of compliance issues are enforcement still in flight, not real drift.
  • Looks at the wider picture. The device’s other open issues, and earlier tickets on the same device and the same rule. A dozen tickets on one rule is one cause, and it reports it as one cause.
  • Verifies on the device after pushing a fix, not on its own dispatch. It does not call a push a fix.
  • Ends every run with a note. First line the outcome, last line the one thing you have to do.

​
What it fixes on its own

Whatever the enforcement behind the control lets it re-push:
  • Re-sending a configuration profile
  • Running the control’s script again
  • Re-installing missing software
  • Re-running the enforcers
Most runs are exactly this, and the employee never hears about it.

​
When it writes to the employee

Primo AI writes to an employee only when the operating system genuinely needs a person at the keyboard — a login to finish encryption, a passphrase, a restart — and only after everything it could do alone is done.
  • Once per issue. It does not chase.
  • One instruction, in the employee’s language.
  • No internal vocabulary. No Primo screen, status, or control name appears in the message.
  • It asks for a restart, it never performs one.
  • No employee assigned to the device means no message.

​
What it hands back to you

Primo AI stops and hands the ticket to your team when only an admin can decide:
  • An operating system edition Primo cannot manage
  • Hardware past what the fix requires
  • Anything needing a purchase or a credential
  • A re-enrollment
  • An EDR that was never deployed on the device
  • A device that is simply offline, or enrolled in another MDM
The ticket comes back with the diagnosis attached, not as a fresh unknown.

​
What it never does

  • Wipe, lock, retire, or unenroll a device on its own reading
  • Close or reopen a ticket on its own initiative
  • Touch another device, or “the others like it”
  • Change the MDM control or the compliance rule to make an issue go away
  • Claim a fix it has not re-read on the device
  • Keep messaging someone who asked for a human, or asked to be left alone

​
The bounds of one run

One ticket, one issue, one device. One fix attempt per mechanism. One message per issue. Ending a run with the issue still open is a valid outcome, and the note says so plainly.

​
Troubleshooting

Primo AI posted a note but did nothing on the device
  • Check the state chip on Compliance > Compliance issue settings. With no published policy, runs stop without acting.
  • Check whether the control behind the issue can be re-pushed per device. Some cannot — see Limits and platform constraints.
  • Check whether the device is offline. Primo AI hands offline devices back rather than queueing work against them.
The same rule keeps raising tickets on the same device
  • Read the latest note. Primo AI looks at earlier tickets on the same device and rule, and reports the shared cause rather than repeating the fix.
  • The cause is usually a control that cannot enforce on that device, not a drifting device.