Turn a low-disk alert into a brief: severity, likely consumers, a safe-cleanup order, and
a deep link. With no RMM connected, degrade to generic guidance plus ticket history and
say the live disk view is unavailable.
1. Resolve the device in the RMM (organization first, ranking by org match then
last-contact; don't stop to ask mid-lookup) and read its details for volume numbers.
Severity: under 5% or under 5 GB free on a system volume is act-now (services and
updates start failing); under 15% is soon.
2. Read evidence without touching the machine: which volume is full (system vs data
changes the playbook), alerts for how long pressure has built (creep vs spike), recent
activity for correlating events (failed patch run, backup writing locally, recent app
install). Check whether another tech is already on the device.
3. Infer likely consumers by device role — hypotheses ranked by evidence, not findings.
Workstations: user profiles, downloads, OneDrive cache bloat, shadow copies, Windows
Update leftovers. Servers: log growth (IIS/SQL/app), backup staging, WSUS and update
caches, database files, shadow copies. A sudden spike: runaway log or dump file.
4. Safe-cleanup sequence, decreasing safety: (a) empty recycle bins and temp/update caches
via Disk Cleanup or Storage Sense; (b) clear stale user profiles per policy; (c) prune
or archive app logs after confirming nothing needs them; (d) shrink shadow-copy
allocation only with the restore-point impact understood; (e) anything touching
databases, backup chains, or app data is change-controlled, not cleanup. Never delete a
file you cannot identify — moving data beats deleting it.
5. Link any client- or device-specific cleanup SOP from the knowledge base, and hand the
tech a deep link into the device in the RMM; remediation is hands-on. Offer the brief
as a note (apply the PSA Note Discipline base skill — plain text, no markdown or
emojis).
6. After the tech confirms cleanup, re-read the details and report before/after free
space. Pressure returning within days is a root-cause/capacity ticket, not a repeat
cleanup.
Guardrails: no script execution, no automated deletion — every destructive step is the
tech's, by hand. Consumers are inferred, not observed (the RMM does not expose per-folder
usage): say so. On servers, anything beyond temp and log hygiene needs a maintenance
window and user-impact confirmation. Never present the third cleanup as a fix.
As a Flow: your entire reply is the brief, posted verbatim — severity, hypotheses labelled
as such, safe-cleanup sequence, deep link. Device unresolvable or volume data unreadable
-> output nothing. Another tech recently active -> lead with "TECH ALREADY ENGAGED -
coordinate before acting". The note is the only permitted write: no script execution, no
deletion, no device actions.
Magic Library