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 rule with a list of conditions that all have to hold (organisation, device attributes, inventory or custom fields, each one negatable), an explicit priority (lower wins) and an action: assign one named Policy and/or add Sensors and Jobs from the library. Among the matching rules the lowest priority that assigns a policy decides the policy; the items of every matching rule are added. No event triggers, no schedules, no other actions. 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 device attribute defined in Collections. Field types are Text, Multiline, Table, and Secret. Data sources can be Manual entry, a parsed Job result, or a SQL query. A manual field marked inheritable can also hold values on group, location, tenant and global level, which a device without a value of its own inherits. Custom fields render as tabs and sections on the device detail page; scripts read them through variables and can write them back. 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.

Public API. The REST API under /v1 of the server, used by external systems with a Bearer token created under Settings → API tokens. A token is bound to a console account and carries scopes, a tenant scope and a rate limit; the server serves its own Swagger reference at /docs. See X.9.

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.

Script variable. A token of the form {{namespace.key}} in a script, resolved per device when the script is handed out: device for built-ins such as the device name, field for a custom field with inheritance, and tenant, location, group and global for one level. Each variable also has a native environment name such as NL_FIELD_AV_OU_ID. See Script variables and custom fields in scripts.

Secret field. A custom field of type Secret. Its values are stored encrypted, shown masked in the console and never returned by the public API; revealing one needs collections_custom_fields_reveal_secrets and is audited. See Chapter 8.4.

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.

Write-back. Setting a custom field value from a script with Set-NetLockField, nl_field_set or a hand-written NETLOCK_FIELD_SET: marker line. The value is stored on the device the script runs on with the source script. See Write custom field values from a script.