Skip to content
flowlakes FlowLakes documentation home

Devices

A device is not a new kind of record. It is a configuration item your CMDB already knows, with an RMM agent linked to it. Three words describe the same machine at three different depths: an asset is what discovery found and what you own; a CI is that asset’s place in your service model; a device is a CI with an RMM agent reporting its live health and carrying out the actions you approve on it.

When you’d use it

  • See whether a machine is healthy right now, not only what discovery found about it last sweep: online state, CPU, memory, disk, pending updates, encryption.
  • Give a technician a script library they can trust, so a proposed fix is always a named, reviewed script, never text a model wrote on the spot.
  • Hear about trouble the moment it happens, not on the next scheduled scan.

What you manage

  • Enrolling a device for RMM happens on the agent itself, at install (register --rmm --system), never from a connection setting. The Create Agent dialog on the Gateway page offers this as a choice, Discovery or Managed endpoint: pick Managed endpoint and the install commands it shows already carry the right flags. See Connect the device door.
  • The device door (/admin/connections) is the one connection that lets an agent propose an action on a device. Same guide.
  • The script library (/admin/device-scripts), under platform.devices.scripts.manage. Every row names a script a run_script action may use, by name only: an agent proposing an action picks a script from this list, never a body it wrote itself. The list groups rows by script name, with a chip for each operating system that name covers, so “disk cleanup” shows once with a Windows chip and a macOS chip rather than as two unrelated rows. The library ships with a built-in catalog per operating system, for example disk cleanup, flush DNS, and restart print spooler on Windows. Editing a built-in script’s body marks it as your own; a later platform update to the catalog never overwrites that edit. The Device panel’s own “Run script” picker reads this SAME library through the device’s inventory (name, description, risk grade, and declared parameter names only, never the body), so a technician who can act on a device but does not hold platform.devices.scripts.manage can still pick a script to run. The library ships with a built-in catalog per operating system, for example disk cleanup, flush DNS, restart print spooler on Windows, and a read-only system information script (hostname, OS version, uptime, disk and memory) on every OS. Editing a built-in script’s body marks it as your own; a later platform update to the catalog never overwrites that edit. Some built-in scripts, disk cleanup and clear temp files among them, verify that they actually helped: once the script finishes, the platform checks that the device’s fullest disk is less full than it was before the script ran, and shows that check’s result on the plan. The Device panel’s own “Run script” picker reads this SAME library through the device’s inventory (name, description, risk grade, and declared parameter names only, never the body), so a technician who can act on a device but does not hold platform.devices.scripts.manage can still pick a script to run.
  • The Devices list (/devices, under Endpoint management in the sidebar) is the platform’s standard list over every managed device: sort any column, show or hide columns, save your own views, export, and page through a large fleet on the server, the same list surface every other table in the platform uses. By default it shows hostname, online, CPU, memory, the fullest disk, pending updates, encryption, last heartbeat, agent version, and the device’s configuration item and agent (each a link). Clicking a row opens that device’s own configuration item with the Device tab already selected (/cmdb/cis/{id}?tab=device). Two facts you might expect here live elsewhere instead: the device’s operating system (on its configuration item) and its open alert count (its own list, below). Neither is a column this table actually holds. With no managed device yet, the page names the Device Monitoring and Device Door packages (with an install link for whichever one you have not added) and offers an “Enrol a device” link straight to the Create Agent dialog with the Managed endpoint choice already selected.
  • Endpoint management’s Device alerts and Device scripts entries hide from the sidebar when their own package is not installed (Device Monitoring for alerts, Device Door for scripts); the Devices list itself stays visible, since it reads the core device-state table every RMM-enrolled agent writes to, with or without either package.
  • An enrolled agent that has never connected shows as “Pending”, the same word in the Gateway agents list and in its detail card, until its first real heartbeat moves it to Active.
  • The device’s live state shows on its configuration item’s Device tab: the same facts as the list, plus metric history, disks, services, and the Reboot/Run script/Restart service actions. A technician starts a device action from here, the same governed plan the device door uses.
  • The RMM column on the Gateway page shows whether an agent is enrolled, how it is running (for example as the device’s own service account), and when it last reported metrics.

Device alerts

Device alerts (/tables/device_monitoring_findings, also under Endpoint management) is this fleet’s own open-findings queue, a separate list from the Devices list above, not a column on it. A device’s state is checked the moment it changes, not on a schedule: a disk filling up, memory staying high, updates piling up are caught within moments of the push that reported them, not on the next scheduled scan. Five alerts ship built in:

AlertPriorityRaised when
Disk nearly fullHighA device’s fullest disk reaches 90% used
Memory exhaustedHighMemory usage stays at or above 95% for more than 5 minutes
Device offlineMediumAn RMM-enabled device misses three heartbeats in a row
Updates pendingMediumA device reports 10 or more pending operating-system updates
Disk not encryptedMediumA device reports its disk encryption off

Each one closes itself automatically the moment the device’s next report no longer matches: free the disk, and the alert for it clears on the next metrics push. Install the Device monitoring package from the blueprint marketplace to turn these on for your tenant.

Reporting a slow device

The Device monitoring package also adds “My device is slow” to the Service Hub catalog, under IT Services. It is an ordinary service request: it routes and tracks the same way any other request does, and it never starts an agent run or a device action by itself.

Fleet sizing

Device traffic enters through its own lane. Heartbeats and metrics pushes take a small, separate share of the database connections, so a burst from a large fleet waits in that lane and never slows the ticket and request pages. A device that pushes too often is told to wait: the answer carries a Retry-After time, and the agent honours it before it tries again. The defaults allow six calls per minute per device and six thousand per minute per tenant, which fits a thousand devices on the standard cadence. A heartbeat that reports nothing new is only noted, not written, so a quiet fleet costs almost nothing.

Processing happens in the background on the intake queue, where every tenant gets a fair share: one tenant with many devices cannot hold up another tenant’s alerts or rules. Sizing above ten thousand devices on one tenant is a conversation with your account team; the limits above can be raised per installation.

Good to know

  • A device is never counted twice. The same configuration item the device door acts on is the one discovery already found and your CMDB already tracks; enrolling it for RMM links an agent to it, it never creates a second record.
  • RMM is opt-in, on purpose. An agent you already run for discovery gains no ability to act on its own device until you register it again with RMM turned on. Nothing in the cloud can turn it on for you.
  • A script runs by name only. An agent never writes or edits a script body; it names one from your library, and the device itself checks that the body it receives matches what you saved before running it.