Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
Our help docs have a new home! Looking for the old help center? Visit docs.getthread.com.
ImmyBot
Role: Technician
Outcome: Faster Resolution & Response
When to use: “Did the ImmyBot maintenance run for <client> last night? Anything fail?”, “why didn’t <application> install on <device>?”, or checking which machines are enrolled at all.
Run it: on one computer, or across a whole tenant/maintenance window, on demand (not a Flow — it’s a read-only review, not a per-ticket event).
Answer ImmyBot deployment questions from session history instead of guesswork. Read-only. Requires ImmyBot; if not enabled, say so and stop — do not substitute RMM data as if it were deployment history.
1. Resolve the client to an ImmyBot tenant. Rank name matches and state your pick; only ask when genuinely ambiguous.
2. Scope the question: whole-tenant, one computer, or one maintenance window.
3. Tenant review: pull the ImmyBot enrollment list (flag result caps — report floors). Then read the maintenance-session history over the window (default last 7 days) and bucket sessions: succeeded / failed / partial / not-run. Group failures by what failed (a software's detection or install step, a pending-reboot precondition, machine offline at session time) and by machine — a machine failing every session is different from a package failing on every machine.
4. Single computer: pull the computer's ImmyBot identity and state, then its maintenance-session history — what ran, what failed, and the failure detail per step. Correlate "offline at session time" failures with the RMM view if a health check has been run.
5. Read the failure texture before concluding: installer exit codes and detection-script failures point at the package; timeout/unreachable points at the machine or network; a pending reboot blocking everything points at basic hygiene. Report what the session record actually says, quoting the failing step's status rather than paraphrasing into certainty.
6. Output: coverage count, session outcomes over the window, failure clusters (by package and by machine) with evidence, and recommended next actions — retry after reboot, fix the package, enroll the missing machines. Offer a plain-text summary note (no markdown/emojis).
Guardrails: read-only today — this integration cannot start, retry, or modify maintenance sessions, and cannot deploy software; every "retry"/"fix" is a recommendation for a tech to action in ImmyBot, never claimed as performed. Do not infer success from absence — a machine with no session in the window "did not run", which is not "passed". Failure causes come from the session record; where ambiguous, say so instead of picking a cause. Result-cap honesty on computer and session listings.
Was this page helpful?