Only alerts that stay open become tickets. DaemonLayer investigates, fixes them with scripts you approved, verifies the fix, or hands a technician a ticket that is already half-solved.
Connecting your RMM gives DaemonLayer three things: alerts it can work, devices it can check, and scripts it may run. Fewer tickets, and better ones.
An alert only becomes a PSA ticket once it has stayed open for the grace period. DaemonLayer then checks the device's last 30 days of alerts, finds similar past tickets and how they were fixed, and can run up to two read-only diagnostics, such as an event log query, before it decides.
For problems local to the user's own Windows computer, DaemonLayer finds their device, searches its installed software, optionally runs a diagnostic, and picks a fix from the scripts you allowed. A technician approves it, the script runs, and the user is asked to try again.
Only offered when it can actually help: a device is found, a script is allowed, and the problem is on the device— not accounts, licences, M365 or the network.
How device troubleshooting worksWhen a user reports a problem, triage sees their devices: hostname, operating system, online state and last seen. Technicians stop asking "which computer?", and DaemonLayer never shows or acts on a client's whole device fleet because a user asked.
No manual mapping: devices are matched to users automatically.
An alert that became a ticket is never silently dropped. If DaemonLayer can't prove it fixed the problem, a person gets it.
Waits out the grace period, creates the PSA ticket, checks 30 days of alert history and similar past tickets, and may run up to two read-only diagnostics before it decides: fix or technician.
Re-checks in code that the script is still allowed, asks a technician to approve, runs it through Datto, then verifies the alert actually cleared before anything is closed.
When automation stops, the technician gets one internal note: why it escalated, what was found, suggested first checks from past tickets and your documentation.
For user tickets about their own Windows computer. Checks installed software and diagnostics on that device, proposes an approved fix and asks the user to confirm it worked.
DaemonLayer prefers a technician over a risky fix. Hardware errors, the same monitor failing on several devices (likely a shared cause), recurring alerts or low confidence all go to a person, with one internal note that explains what automation already did.
Every Datto component starts Disabled. You allow scripts one by one, write when the agent should use each one, and the AI only picks from that list. The checks that matter run in code, not in the AI.
DaemonLayer never reboots, deletes or reconfigures Datto itself.
Devices sync every hour. DaemonLayer links devices to users from several exact-match signals, so there is no mapping spreadsheet to maintain. Admin and built-in accounts never link a device to anyone, devices not seen for 90 days are ignored, and re-imaged duplicates resolve to the most recent.
Technicians can review every link on the client's Devices tab and set a manual override when they want to. An override always wins and never expires.
Connecting Microsoft 365 makes device matching much more reliableCreate an API key, connect, allow your scripts. DaemonLayer works through the Datto agent you already run; there is no DaemonLayer agent to deploy.
Enable API access in Datto RMM and generate a key and secret for a dedicated DaemonLayer user.
Pick your Datto region, paste the key and secret, and test. Sites whose names match your clients are linked automatically.
Every component starts disabled. Allow the ones you trust, write when to use them, and switch on the workflows.
Start with diagnostics: they are read-only and make every decision better. Use whatever components you already run in Datto; these are common starting points.
Common questions about this integration
Datto RMM today, with more vendors coming. The RMM integration is vendor-neutral by design: alert handling, device context, the script allow-list and every safety check work the same way for each RMM we add.
No. An alert has to stay open for a grace period (10 minutes by default) before it becomes a ticket. Most alerts clear themselves and never reach your PSA. Muted alerts and alerts from Datto sites that aren't linked to a client are dropped, and a repeat of a monitor that already has an open ticket is added to that ticket as a note.
No. Scripts that reboot or shut down a device, uninstall software, wipe or format, remove users, touch BitLocker, disable networking or can expose secrets are always blocked. They show a lock icon and cannot be enabled, whatever you configure. DaemonLayer also never reboots, deletes or reconfigures Datto itself.
Only the Datto components you explicitly allow, one by one. Every component starts Disabled. You can set it to Diagnostic (read-only, used to gather evidence) or Remediation (used to fix, with technician approval when HITL is on), and you write the guidance for when the agent should use it. The AI only picks from that list.
DaemonLayer re-checks the alert after a configurable delay (15 minutes by default). If it has cleared, the ticket is closed in DaemonLayer, your PSA and Datto. If it is still open, the ticket goes to a technician. Each ticket gets one remediation attempt; a second problem always goes to a person.
No. Devices sync every hour and DaemonLayer works out who uses which device from exact-match signals such as login history and, with Microsoft 365 connected, Entra device owner and sign-in activity. Technicians can review the links and set a manual override, but it is optional.
Only once it becomes a triaged ticket. Alerts that clear during the grace period, muted alerts and repeats added to an existing ticket do not count.
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →