Connect the device door (RMM)

The device door lets an agent read a managed device’s live state and propose an action on it: run a named script, restart a service, kill a process, or reboot. A person approves the action before anything runs, and the gateway agent carries it out on the device itself.

Goal

Enroll a device with RMM turned on, enable the device door, and decide which actions a technician may approve.

Before you start

You need:

A FlowLakes gateway agent already installed on the device (the same agent discovery uses), version 0.10.0 or later.
platform.gateway.write, to manage gateway agents.
platform.external.config.write, to enable the device door connection.

Enroll the agent for RMM

RMM is off by default on every gateway agent, including one you already use for discovery. Turning it on is a decision made at install time, on the device, never from the cloud. The easiest way to make that decision is in the Create Agent dialog on the Gateway page: choose Managed endpoint instead of Discovery, and every install command it shows you (the one-line installer, the PowerShell command, and the copy-paste install-script) already carries the right flags.

On the device, register the agent with register --rmm instead of a plain register (the Managed endpoint choice does this for you). This writes rmm.enabled: true into the agent’s own local configuration; nothing in FlowLakes can flip this flag for you, and an agent you already installed for discovery keeps its network scan and gains no device actions until you register it again with this flag.
Install the agent as a system service, running as the device’s own service account rather than a signed-in user, with install-service --system (again, part of the Managed endpoint choice). On Windows this registers a Scheduled Task as NT AUTHORITY\SYSTEM; on Linux a systemd unit as root; on macOS a LaunchDaemon. A per-user install (the default without --system) keeps working for discovery, but device actions need the elevated, always-running service. A SYSTEM-level install does not see a signed-in user’s PATH, proxy, or certificate settings; configure those machine-wide if the device needs them.
An agent registered this way reports itself as an endpoint agent: it inventories and monitors only the device it runs on, and it never starts a network scan of its own. A gateway agent (registered without --rmm) keeps scanning its network as it does today. The two roles exist so that enrolling a hundred endpoints for RMM never turns into a hundred identical network sweeps.

You know enrollment worked when the device’s row on the Gateway page shows RMM as on, with how it is running (for example NT AUTHORITY\SYSTEM) and when it last reported in.

Enable the device door

Open the blueprint marketplace (where you installed other door packages) and install Device door if it is not already installed. It arrives disabled, like every other door, and it needs no credential: the agent’s own registration is the trust. Once installed, it shows up in Admin, Connections.
Turn it on, and set its posture the same way you would for any other connection. At Observe, an agent can only note what it would change; no device action can be planned until you move the posture to Assist or Trusted.
There is exactly one device door per tenant. You cannot create a second one, and nothing here asks you to.

Decide what a person may approve

A device action is never a model’s direct call. An agent proposes a step, naming the device and the action; a person approves it; only then does the gateway agent run it and report back.

Action	Risk	What it does
Run a script	Comes from the script’s own risk grade	Runs a named script from your script library on the device. See Devices for the library itself
Restart a service	Medium	Restarts a named service and reads its status back afterward
Kill a process	Medium	Stops a process by id or exact name, never a pattern
Reboot	Medium	Restarts the device. The plan stays open until the next heartbeat reports a later boot time
Check service status	Low	Reads a named service’s current status. No change to the device

Set who signs off on each risk level under Approval Policies, or keep the platform default.

You know it worked when

A technician on an incident sees the device’s state and open alerts, proposes an action such as restarting a stuck service, a person approves it, and the case file shows the action, what it changed, and a verified result once the device’s own heartbeat confirms it.

Not in this guide

Remote shell or screen sharing, and a gateway rail sized for very large fleets, are named in the program as later work, not built here. Patch installation stays with your existing patch tool; this door only reads pending updates.

Troubleshooting

Symptom	Likely cause	Fix
An agent proposes no device actions on an incident	RMM was never turned on at registration, the device door is off, or its posture is still Observe	Re-register the agent with `--rmm`, or turn on the connection and move its posture to Assist
A proposed action is refused the moment it is created	The device is offline, the agent has not reported `rmm_enabled`, or the named script does not exist for this device’s operating system	Check the Gateway page for the device’s last heartbeat and RMM status; confirm the script is in the library for the right operating system
A reboot plan stays open longer than expected	The device has not yet reported a heartbeat with a later boot time	Wait for the next heartbeat; the plan settles automatically once it arrives, within 15 minutes

How it connects

The script library, device alerts, and where a device’s live state shows up: Devices.
How approvals and risk grades work generally: External capabilities.
Devices land in the CMDB through the same inventory every agent reports: CMDB and discovery.