Glossary

Alphabetical reference for terms that carry a specific NetLock RMM meaning. When a term is ambiguous in general IT usage, this glossary reflects what the product does, not what the word means elsewhere. Every entry points to the chapter that owns the subject in full.

A

Agent. The software installed on every managed device. It reports status, runs scheduled Jobs and Sensors, enforces the assigned Policy, and terminates remote-access sessions on the device side. Supported on Windows, Linux, and macOS. See Chapter 2 — Core Concepts and Chapter 3 — Devices.

AI Chat. The conversational surface at /ai-chat that operators use to ask an LLM about devices, events, or scripts, and optionally save generated scripts back into Collections. Off by default; configured under Settings → AI / LLM. See Chapter 13 and A.11.

App Hub. The software catalogue under Collections. Entries come from Winget (Windows), Flathub (Linux), Chocolatey, or manual scripted packages. The App Hub itself is a catalogue, not a deployment engine — actual installation runs through Software Deployment. See Chapter 8.5.

Application Control. The allowlisting feature under Collections. Rulesets define which applications may execute on Windows devices, matched by path, metadata, hash, or code-signing certificate. Rulesets attach to devices through Policy Settings → Windows → Application Control. See Chapter 8.6.

Audit. The immutable administrative trail at /audit. Every configuration change — user created, policy saved, automation edited — is recorded with the acting user, source IP, and timestamp. Distinct from Events. See Chapter 12.

Authorized device. A device that has been approved from the Unauthorized queue and now appears in the main inventory. Contrast with Unauthorized device. See Chapter 3.2.

Automation. A condition → policy rule. The condition matches a device attribute (Device Name, Tenant, Location, Group, Internal IP, External IP, or Domain) and the action assigns one named Policy. Automations are evaluated in priority order — first match wins. No event triggers, no schedules, no actions other than assigning a policy. See Chapter 5.

B

Brand template. A reusable cover-page, colour, logo, and PDF-footer bundle applied to generated Reports. Managed on the Brands tab of the Reports page. See Chapter 11.

C

Collection. The umbrella for eight reusable libraries — Scripts, Jobs, Sensors, Custom Fields, App Hub, Application Control rulesets, Device Control entries, and Software Deployments. You build library items once and reference them from Policies, Automations, or standalone actions. See Chapter 8.

Community. The integration layer that connects a deployment to the shared NetLock RMM catalogues of Scripts, Reports, and Whitelabeling themes. Not a standalone page — each community surface lives inside its parent feature. Authentication is deployment-level through a Members Portal API key. See Chapter 15.

Custom field. A per-device attribute defined in Collections. Field types are Text, Multiline, and Table. Data sources can be Manual entry, a parsed Job result, or a SQL query. Custom fields render as tabs and sections on the device detail page. See Chapter 8.4.

D

Dashboard panel. A widget on a Dashboard, backed by a SQL query. Panels are composed in the Panel Builder and constrained by the allowed-tables list in Settings → Dashboards. See Chapter 2 and A.12.

Department. In the Ticket System, a team-level container holding its own mailbox, operators, SLA defaults, templates, and webhooks. Every ticket lives in exactly one department. See Chapter 10.9.

Device. A managed computer — workstation, laptop, or server — that runs the Agent. Devices carry a hostname, a human-readable label, one Policy at a time, and any Custom Fields defined for the deployment. See Chapter 3.

Device Control. The USB-peripheral allowlisting feature under Collections. Entries match by vendor id, product id, serial, or device class, and scope to a device, tenant, location, group, or globally. New entries are created through the approval flow on the Blocked Devices tab, not a create dialog. See Chapter 8.7.

E

Events. The operational activity stream at /events. Events record things that happened on or to devices — script results, sensor breaches, policy deployments, antivirus detections. Contrast with Audit, which records configuration changes. See Chapter 12.

G

God Mode. A deployment-wide toggle that unlocks a raw-SQL editor inside a content surface. Three feature areas expose their own God Mode switches — Dashboards, Reports, and Custom Fields — each under its Settings sub-page. God Mode is a platform decision, not a per-user permission: when on, every user who can edit the feature can write unrestricted SQL. See A.12.

Group. The innermost level of the tenant hierarchy. A group belongs to exactly one location, which belongs to exactly one tenant. Groups are typically used to reflect device role or configuration rather than physical location. See Chapter 4.

J

Job. A Scripts-plus-schedule binding under Collections. A Job says "run this Script on the device on this trigger" — System Boot, a fixed Date/Time, a recurring interval, or recurring on named weekdays. A Job may be marked hidden, in which case it is excluded from Events and typically drives a Custom Field. Not to be confused with an operating-system scheduled task. See Chapter 8.2.

L

Label. A free-text display name for a device, editable per-device. The label replaces the hostname in Console lists, event feeds, reports, and audit entries. See Chapter 3.1.

Location. The middle level of the tenant hierarchy. A location belongs to exactly one tenant and contains one or more groups. Typically maps to a physical site. See Chapter 4.

M

Members Portal. The external identity and catalogue service that NetLock RMM uses for community features (Scripts, Reports, Themes). Authentication is deployment-level via a single API key stored in the Console settings. Individual operators do not sign in to the Members Portal. See Chapter 15.

P

Policy. A named bundle of desired device configuration — agent behaviour, tray icon, Windows Defender, Application Control, Device Control, Linux UFW, Sensors, Jobs, per-platform patch rollout, and App Hub exposure. A device is assigned at most one Policy at a time. No layering, no merging, no versioning, no rollback. See Chapter 6.

R

Relay. A server-side tunnelling service that lets the Console reach a device's TCP port through a relay connection when a direct connection is not possible. Used for Remote Control and for ad-hoc TCP forwarding. See Chapter 9.2.

Remote Control. The live screen-and-input session surfaced from the Console, delivered as H.264 video over the Relay when available and falling back to JPEG frames over SignalR when the Relay cannot carry the session. The product does not use VNC or RDP. See Chapter 3.5 and A.7.

Ruleset. In Application Control, a named list of rules that together form an allowlist for a set of devices. A ruleset is attached to devices through Policy Settings → Windows → Application Control. See Chapter 8.6.

S

Script. A snippet of PowerShell, Bash, Zsh, Python3, or MySQL stored in the Scripts library under Collections. Scripts run ad-hoc from the device detail page, on a schedule via Jobs, as the action of a Sensor breach, or from a remote shell. See Chapter 8.1.

Sensor. A per-policy metric collected by the Agent on an interval — CPU, memory, disk, an event log matcher, a ping, an SNMP probe, or the output of a script. Sensors carry severity-based thresholds for notification and for triggering an action Script. See Chapter 8.3.

Server. The central service the Console reads from and Agents report to. In a cloud deployment the vendor runs it; in a self-hosted deployment the customer runs it. See Chapter 1 — Core Concepts.

SLA. In the Ticket System, a response-and-resolution clock attached to a ticket through its priority and department. SLA states are Compliant, At Risk, and Overdue; thresholds are configured per priority. The Patch Management page uses the same three states against default thresholds (7 / 15 / 30 / 60 days by severity) for patch compliance. See Chapter 10.15 for tickets and Chapter 7.4 for patches.

Software Deployment. The packaged-deployment feature under Collections. A four-step wizard composes a target set and a sequence of App Hub entries to install, and the deployment tracks per-device attempt outcomes. The only direct path from the App Hub catalogue to installation on devices. See Chapter 8.8.

SSO. Single sign-on via OpenID Connect. Five providers are supported — Azure AD, Keycloak, Google, Okta, Auth0 — and exactly one can be active at a time. SAML 2.0 is not supported in the current release. See A.4.

T

Tenant. The top-level organisational container. For an in-house IT team it typically maps to the company itself; for an MSP it maps to one customer organisation. Tenants contain Locations, which contain Groups. See Chapter 4.

Ticket. The optional helpdesk unit of work. A ticket has a status, a priority, a department, a contact, an SLA clock, a conversation, a time-tracking log, and an audit trail. See Chapter 10.

Tray Icon. The small application the Agent exposes on Windows, Linux, and macOS devices to end users. Branding and visibility are controlled per-policy; the apps exposed in the tray menu are drawn from the App Hub selections on the policy. See Chapter 6.3.

U

Unauthorized device. A device whose Agent has contacted the Server but not yet been approved. Unauthorized devices sit at /unauthorized_devices until an operator authorises or rejects them. They do not appear in the main inventory. See Chapter 3.2.

W

Whitelist (Device Control). In Device Control, the allowlist of USB and peripheral devices permitted to attach to in-scope devices. The only creation path is the approval flow from the Blocked Devices tab. See Chapter 8.7.

Whitelabeling. The branding feature at Settings → Whitelabeling that replaces logos, colours, and accent text across the Console. Whitelabeling also hosts the Community Themes browser, which imports or publishes full themes. See A.6.