FlowRMM

Operator Guides

Clients, Sites & Endpoint Inventory

Examples use the fictional Acme MSP / Acme Corp / Acme HQ world (one operator-org pattern that also fits internal IT and small teams). Hostnames like acme-wks-01 stand in for your endpoints. Portal URLs use https://portal.example.com as a stand-in.

In the Acme example, inventory sits under client Acme Corp and site Acme HQ. Endpoints such as acme-wks-01 check in with vitals so operators know what they are connecting to.

FlowRMM maintains a centralized inventory of all enrolled endpoints and collects real-time vital metrics to help operators spot issues before they impact productivity.

1. Device Inventory Management

The Endpoints inventory is the primary operator entry for Remote Console: search, filter, and launch remote or console sessions from each row.

Inventory Columns

The client grid displays key information about each agent:

  • Status Indicator: Green (Online), Grey (Offline).
  • Hostname: Resolved from the latest agent inventory snapshot, so endpoint renames appear without changing the stable monitor identity.
  • Client & Site: Hierarchical client/site assignment context.
  • IP Address: The agent's external connection IP.
  • OS Platform: Windows, macOS, or Linux platform identifier.
  • Agent Version: The current version of the agent software running on the endpoint.
  • Last Heartbeat: Relative time since the last successful /monitor check-in.

Inventory Filtering & Search

Operators can find specific devices using search and filters:

  • Search Bar: Searches across hostnames, client names, and site names.
  • Client/Site Filter: Dropdown filters to restrict the view to a particular organization scope.
  • Saved Software Filters: Restricts the list to endpoints that have specific software packages installed (derived from the software inventory snapshots).

2. Vitals & Telemetry Collection

When you click on an active client, FlowRMM displays real-time vitals collected directly from the agent.

Telemetry Pipeline

  1. AgentRuntimeHostedService samples hardware vitals and compiles AgentMetrics snapshots on a configurable interval (resourceSampleIntervalSec from /monitor/config, default loop 30 seconds).
  2. The C# agent submits telemetry batches only over the /monitor WebSocket via MonitorClient.SendTelemetryBatchAsync. HTTP POST /api/v1/telemetry/ingest is a separate operator/webhook ingestion path and is not used by the agent runtime.
  3. The portal merges PostgreSQL registration rows and live monitor inventory via mergeAgentTelemetry when rendering the Clients page (GET /api/v1/agents).

Inventory Snapshots

In addition to vitals, the agent uploads software and hardware inventory snapshots on a timer (default every 15 minutes, configurable via AgentEndpoints__InventoryPollIntervalMinutes). Saved software filters on the Clients page are derived from these snapshots.

Core Telemetry Vitals

The following metrics are collected and reported:

  • Hardware Vitals: cpu.usage.percent, memory.usage.percent, and per-drive disk.{drive}.usage.percent (Windows).
  • Frames Captured: Cumulative count of screen frames captured by the agent.
  • Frames Sent: Cumulative count of screen frames transmitted over remote control channels.
  • Frames Duplicates Suppressed: Duplicate frames skipped by the capture pipeline.
  • Capture Failures: Count of frame-grabber failures (indicates OS permission or display driver issues).
  • Stream Loop Errors: Errors encountered inside the video streaming render loop.
  • Loop Delay (Avg): The average roundtrip processing delay (in milliseconds) of the capture and send loop.
  • Controls Received: Number of operator inputs (clicks, keypresses) processed by the agent.
  • Wake Requests: Heartbeat wake-up pings received by the endpoint.
  • Registration Health: signal.registered, video.registered, registration failure counters, and last registration error codes.
  • Reconnect & WebRTC: Reconnect attempt counts and WebRTC restart metrics from the streaming engine.

3. Client, Site & Device Assignment

The Clients page (/clients) is a core surface available on every plan with inventory.read (including Remote Console). Use it to create client organizations, add sites, and assign endpoints. The global scope switcher in the header also links to Manage clients & sites and offers a Create client Acme Corp shortcut when no clients exist.

For pilot onboarding, the Clients page shows a first-hierarchy checklist:

  1. Create the Acme Corp from the scope switcher CTA or /clients?create=1.
  2. Add a site under that client.
  3. Assign one or more enrolled endpoints to the client/site.
  4. Confirm the new client appears in the global scope switcher.

Azure onboarding is optional for this first step. It remains available only to tenants with graph.manage and should not block core Remote Console hierarchy setup.

The portal exposes client/site hierarchy APIs for organizing inventory:

  • GET / POST /api/v1/clients: List or create client organizations.
  • PUT /api/v1/clients/{clientId}: Rename a client organization.
  • GET / POST /api/v1/sites: List or create sites within a client scope.
  • PUT /api/v1/sites/{siteId}: Update site name, type, or offline-alert policy.
  • DELETE /api/v1/sites/{siteId}: Remove a site. Endpoints keep their client assignment but lose site scope.
  • GET / PUT /api/v1/devices/{deviceId}/assignment: Read or update client/site assignment for a device.
  • GET /api/v1/devices/{deviceId}/groups: List group memberships for a device.

Each site stores an optional offline-alert policy in site metadata (offlineAlertsEnabled). When enabled for a site, disconnect events on endpoints assigned to that site can trigger tenant alert rules with condition offline. Remote or away-style sites typically keep this disabled so laptops going offline do not page operators; data center sites can enable it for always-on infrastructure.

Sites created before explicit policy confirmation inherit defaults from site type (data center alerts on, other types off). The Clients page highlights inherited policies and lets operators confirm them individually or in bulk so alerting intent is stored explicitly.

Installer bootstrap can scope new registrations to a client and site via companyId / siteId query parameters on GET /api/v1/agent/install, which pass --company-id and --site-id to FlowRmm.Agent --register.

DELETE /api/v1/agents/{agentId}?uninstall=true (portal session) removes the agent from portal inventory and, when uninstall=true, queues a remote self-uninstall action on the endpoint before deletion.

Related guides

All docsBook a DemoApply for Cohort 01