NetLock RMM Documentation

Welcome to the NetLock RMM user manual. This site covers everything an IT administrator or MSP technician needs to install, configure, and operate a fleet of devices with NetLock RMM, from the first login through advanced automation and reporting.

The manual is organised into five parts. Start with Part I if you are new to the product; jump directly to Part II or Part III if you already know the core concepts and want a specific feature or task.

Part I — Getting Started & Concepts

Orientation material. Read this part before touching the Console if you are new to NetLock RMM.

• 1.1 What is NetLock RMM? — product overview, deployment modes, and who the product is for.
• 1.2 Core Concepts — tenants, locations, groups, agents, policies, Collections, and permissions.
• 1.3 First-Run Walkthrough — from first login to the first device under management in under an hour.
• 1.4 Navigating the Console — layout, navigation menu, tenant selector, dark mode, and help.

Part II — Console Reference

One chapter per top-level menu group. Use this part when you need to know what a specific page or dialog does.

• Chapter 2 — Dashboard
• Chapter 3 — Devices
• Chapter 4 — Tenants, Locations & Groups
• Chapter 5 — Automations
• Chapter 6 — Policies
• Chapter 7 — Patch Management
• Chapter 8 — Collections
• Chapter 9 — File Server & Monitoring
• Chapter 10 — Tickets (Optional module)
• Chapter 11 — Reports
• Chapter 12 — Events & Audit
• Chapter 13 — AI Chat
• Chapter 14 — Users & Roles
• Chapter 15 — Community (Optional module)

Part III — How-To Guides

Task-oriented recipes. Each guide is short, prescriptive, and links back into Part II for concept reference.

The guides cover deploying the first agent, building and applying a policy, configuring Windows Defender, setting up patching, writing a PowerShell script, deploying software with App Hub, restricting USB devices, configuring notifications, enabling SSO, branding the Console, running compliance reports, remote-controlling a device via relay, upgrading NetLock RMM, replacing the Members Portal API key, reloading licence information after a renewal, and installing the server with Docker.

Part IV — Administration

Deeper reference material for system operators. Covers licensing, updates, database management, security (SSO, IP whitelist), globalization, whitelabeling, remote screen control, notification channels, logging, system settings, AI / LLM configuration, and content defaults.

Start with A.1 System overview & licensing.

Part V — Appendix

Reference tables and quick lookups.

• X.1 Glossary
• X.2 Permission reference
• X.3 Troubleshooting
• X.4 Keyboard shortcuts
• X.5 Integration endpoints
• X.6 Changelog pointer
• X.7 Feature matrix

Conventions used in this manual

• UI labels, routes, and permission flags appear in backticks: Settings → SSO, collections_application_control_manage.

• Navigation paths use → to separate menu levels.

• Callouts flag important information:

  Note: Informational aside worth reading. Tip: Shortcut or recommendation. Warning: Action you probably do not want to take by accident. Optional module: Content only applies when a particular module is enabled.

• Keyboard shortcuts use <kbd> tags, for example Ctrl + K.

What is NetLock RMM?

NetLock RMM is a remote monitoring and management (RMM) platform for IT administrators and managed service providers (MSPs). You use it to deploy an agent to the devices you manage, see their status in real time, apply policies, schedule automations, push patches, run scripts, distribute software, hand out remote-control sessions, and keep an auditable record of everything that happens along the way.

The product is delivered as a web Console backed by a server and an agent you install on each managed device. All three components are covered in this manual; the Console is the main surface you interact with.

Who the product is for

NetLock RMM targets two audiences:

• IT admins inside a single organisation. You manage a single fleet of workstations, laptops, and servers. You typically use one tenant, a small number of locations, and a handful of user accounts for your colleagues.
• MSP technicians managing multiple customer organisations. You create one tenant per customer, organise their devices into locations and groups, apply policies that differ per customer, and scope user permissions so that technicians see only the tenants they are assigned to.

Both audiences use the same Console. The difference is scale — whether you work with one tenant or a hundred — not the feature set.

Deployment modes

NetLock RMM runs in two deployment modes. Functionally they are the same; operationally they differ in who manages the server.

Throughout this manual, sections that apply to only one mode are flagged with a callout:

Cloud only: This section applies only to the hosted deployment.

Self-hosted only: This section applies only to self-hosted deployments.

If neither callout appears, the content applies to both modes.

What NetLock RMM does at a glance

The Console is organised into roughly a dozen top-level feature areas. At the highest level:

• Monitoring. A real-time Dashboard of customisable panels, a device inventory with online/offline status, custom sensors you define, and a website uptime monitor.
• Configuration. Policies that define how devices should be configured (Windows Defender, firewall rules, and more), applied per device or group.
• Automation. Automations that trigger on events or schedules and compose scripts, jobs, and policy actions.
• Patch & software management. Patch Management for operating system patches, plus App Hub and Software Deployment for applications.
• Remote access. Remote shell, remote desktop, and relay sessions that traverse firewalls.
• Governance. Events for operational activity, an immutable Audit trail for admin actions, Reports for compliance, and a role-based permissions model for users.
• Optional modules. Tickets for helpdesk workflows and Community for shared intelligence; each can be disabled per deployment.

The rest of this manual describes each of these areas in detail.

What NetLock RMM is not

Setting expectations up front saves time later:

• It is not a replacement for a dedicated SIEM. The Audit trail is auditable, but large-scale security event aggregation belongs in a SIEM you forward events into.
• It is not an identity provider. You can sign in with SSO (OIDC / SAML), but NetLock RMM consumes identities; it does not issue them.
• It is not a backup product. File Server distributes files to agents; it does not perform image-level backups of managed devices.

How to use this manual

The quickest path for a new deployment is:

1. Read Core Concepts so the vocabulary in the rest of the manual makes sense.
2. Work through the First-Run Walkthrough to get one device under management.
3. Skim Navigating the Console so you know where things live.
4. Jump into Part II for the feature area you need next, or Part III if you want a task-by-task recipe.

For day-to-day reference, use Part II (one chapter per menu group) or Part V (glossary and lookup tables).

Core Concepts

NetLock RMM is easier to learn if you read the vocabulary first. The product uses a small number of terms very consistently, and almost every chapter in Part II assumes you already understand the ones introduced here. Read this chapter end-to-end before jumping into feature documentation.

The agent, the server, and the Console

Three components form the system:

• The agent is a small piece of software installed on every device you want to manage. It reports status, runs jobs you schedule, enforces policies, and provides the endpoint for remote shells and file transfers. Once installed it talks to the server on a regular schedule.
• The server is the central component. It holds configuration, receives data from agents, runs the web Console, and mediates remote-access sessions. In cloud deployments the vendor runs it; in self-hosted deployments you run it.
• The Console is the browser-based user interface you spend your day in. It reads and writes configuration to the server; it does not talk to agents directly.

Every feature in this manual ultimately reduces to "the Console tells the server what should happen, and the agent makes it so".

Tenant, location, group

NetLock RMM organises managed devices into a three-level hierarchy. Every device belongs to exactly one group, which belongs to exactly one location, which belongs to exactly one tenant.

• A tenant is the top-level container. For an in-house IT team this usually maps to "the company". For an MSP it maps to one customer organisation.
• A location is a subdivision of a tenant, usually a physical site or office. A small tenant might have one location; a multi-site customer will have several.
• A group is a subdivision of a location. Groups typically reflect how devices should be configured rather than where they physically are — for example Servers, Workstations, Kiosks.

The hierarchy is primarily an organisational structure for devices and for scoping what users can see. Unlike some RMMs, you do not attach policies directly to a tenant, location, or group. Instead, policies are routed to devices by Automations, which match devices by attributes such as their tenant, location, or group name.

See Chapter 4 for the full reference on managing this hierarchy.

Tip: Group devices by how they should be configured, not just where they live. "Every laptop, regardless of site" is a better group than "every device in the Berlin office" if your policies differ primarily by device type.

Agents and devices

A device is a managed computer — a workstation, laptop, or server. When you install the agent on a new device, it contacts the server and registers itself as an unauthorized device: present on the network, but not yet accepted into a tenant. An administrator reviews unauthorized devices in Devices → Unauthorized, chooses the tenant, location, and group to assign them to, and approves them. From that moment the device is an authorized device and appears in the main device list.

Note: Agents that have never been approved are the most common source of "missing device" support tickets. The First-Run Walkthrough covers the approval flow in detail.

Devices also carry a label (a free-form human-readable name), custom fields defined at the Collections level, and any number of per-device settings. Chapter 3 is the canonical reference for everything device-related.

Policies

A policy is a named bundle of desired configuration for a device. Examples: "managed laptops — strict", "kiosk devices", "server baseline". A single policy can configure:

• General agent behaviour (sync interval, auto-update).
• Tray Icon branding and visibility.
• Windows Defender Antivirus — exclusions, scan jobs, notifications.
• Windows Application Control and USB Device Control rulesets.
• Linux UFW firewall.
• SNMP sensors to collect on devices.
• Scheduled Jobs to run on devices.
• Patch Management rollout rules, per platform (Windows, Linux, macOS, Docker).
• Which App Hub apps are exposed in the Tray Icon.

Policies are edited in the Policy Settings page and stored in the server database. The agent picks up changes on its next sync (5-1440 min, configurable per policy).

Important: NetLock RMM does not keep a policy version history and does not support rolling back to a previous policy state. Edits apply in place. If you need a safety net, clone a policy before making a risky change.

A device is assigned at most one policy at a time. Policies are not layered or merged.

Automations

An automation in NetLock RMM is narrower than the word implies in other products. It is a rule that decides which policy gets assigned to which device, based on a simple condition:

IF a device's <attribute> matches <expected value>  THEN  assign policy <name>

<attribute> is one of: Device Name, Tenant, Location, Group, Internal IP-Address, External IP-Address, Domain.

There are no event triggers, no schedule triggers, no manual triggers, and no actions other than assigning a policy. Automations do not run scripts, send notifications, create tickets, or chain steps. Their only job is to route policies to devices.

When a device syncs, the server evaluates all automations in priority order. The first rule whose condition matches the device determines the device's policy. If no rule matches, the device has no policy. Adding, editing, or deleting an automation forces every connected device to re-evaluate immediately.

The practical consequence: to give devices a policy, you need both a Policy and at least one Automation whose condition matches those devices. A policy on its own is inert.

For event-driven work — "run a script when a disk fills up", "open a ticket when a sensor breaches a threshold" — NetLock RMM uses Sensors (with action scripts) and Jobs (scheduled scripts), not Automations. See Chapter 8 — Collections.

Collections

Collections is the umbrella term for reusable building blocks you create once and reference from many places. Eight kinds of Collection item exist:

Collections items are cross-referenced: an automation may invoke a script, a policy may include an Application Control ruleset, a software deployment may use App Hub entries. Chapter 8 documents each in detail.

Permissions

NetLock RMM uses a role-based permissions model. Each user holds a set of permission flags that gate access to Console features. Flags come in three shapes:

• *_enabled — whether the user sees the feature at all (for example collections_enabled).
• *_add — whether the user can create new items in the feature.
• *_manage — whether the user can edit or delete existing items.

Permission flags control which items appear in the navigation menu on the left, which buttons are visible on a page. A user without dashboard_enabled will not see the Dashboard menu item; a user with collections_application_control_enabled but without collections_application_control_manage will see the Application Control page read-only.

Permission names appear throughout this manual in backticks, for example collections_application_control_manage. See Users & Roles for how to assemble permissions into roles, and the Permission reference appendix for a full list.

Real-time updates

Several parts of the Console update in real time using a persistent connection to the server. Device status, script and job execution results, and policy deployment notifications all flow in without a page refresh.

What to read next

• First-Run Walkthrough — apply these concepts to a fresh deployment.
• Navigating the Console — where each concept lives in the UI.
• Glossary — one-line definitions for quick lookup.

First-Run Walkthrough

This chapter takes you from your first login all the way to a managed device that is online, labelled, and has a policy applied. It assumes the server is already running (whether cloud or self-hosted).

Before you start, read Core Concepts if you have not already. Every step below uses terms introduced there.

Step 1 — Sign in

Open the Console in your browser. The login screen accepts either an username or email address and password, or a configured single-sign-on provider if your organisation has enabled SSO.

1. Enter your email in the Email field.
2. Enter your password in the Password field and sign in.
3. If your account has two-factor authentication enabled, enter the current code from your authenticator app on the next screen.
4. If your organisation uses SSO, click the SSO button on the login page instead and complete the provider's flow.

You land on /account/home, a small personal dashboard showing your profile information, navigation order menu and email signature configuration for the ticketing system.

Note: If you are the very first user on a self-hosted deployment, the initial administrator credentials were set during server installation. Default username is: "admin" and default password is "admin".

Step 2 — Complete the Setup Wizard

The first time an administrator visits the Dashboard page, the Setup Wizard opens automatically. It walks you through the minimum configuration needed to get the product useful:

1. Create a tenant (if none exists yet).
2. Create a location under that tenant.
3. Create a group under that location.
4. Optionally generate an agent installer for one of your supported platforms.

If you dismiss the wizard, the same steps are available manually from the Tenants menu and the Agent Download dialog. The wizard is simply a faster path.

Tip: Name your first tenant deliberately. It is common to use the company or customer name. You can rename it later, but external integrations (for example reports emailed to stakeholders) use the name you set here.

Step 3 — Create a tenant, location, and group

If you skipped the wizard, do this manually:

1. In the left-hand navigation, open Tenants.
2. On the Manage Tenants page, click the add button and fill in the tenant name and basic details. Save.
3. Select the new tenant in the list to enter its detail view. The Console stores the selection so subsequent screens act on this tenant.
4. Open Location Settings and add a location — typically a physical site ("Berlin HQ", "Remote Workers").
5. Inside the location, add one or more groups. Groups should reflect how devices will be configured; a good starter set is Workstations, Laptops, and Servers.

See Chapter 4 for the full reference on the tenant page and its dialogs.

Step 4 — Generate an agent installer

With a target group in place, you can generate an installer that pre-configures the agent to register into that specific tenant, location, and group. NetLock RMM ships the agent as a single self-contained executable per platform and architecture, with the server configuration embedded at build time.

1. Open the Agent Download dialog from the Setup Wizard or from the Devices page.
2. The dialog runs as a five-step wizard. Step through:
   1. Configuration name — a label for this installer build.
   2. Deployment method — select the target tenant, location, and group.
   3. Target server — select the communication, remote, update, trust, file, and relay servers this agent will talk to.
   4. Authorization — choose whether the agent is pre-authorized or registers as unauthorized pending admin approval.
   5. Platform and architecture — choose one of win-x64, win-arm64, linux-x64, linux-arm64, osx-x64, osx-arm64. Also choose Standard Installer (console, silent-capable) or GUI Installer (graphical, with customisable window title, welcome message, and button labels).
3. Click the build action. The Console packages a binary with the embedded config into a .zip and returns a download link.
4. Optionally download an accompanying install script — Install-NetLockAgent.ps1 for Windows, Install-NetLockAgent.sh for Linux or macOS — that automates the download, extract, and run steps.

Warning: Treat agent installers like secrets. The server configuration is embedded inside the binary, so anyone with the installer can register a new device into the configured group, depending on your configuration settings. You can also set a installer to auto authorize until a certain date and all installations originating from the specific installer will first land under unauthorized devices.

Step 5 — Install the agent on a device

On the target device, copy the .zip, extract it, and run the binary with administrator or root privileges.

Windows (PowerShell, elevated):

Expand-Archive .\NetLockAgent.zip -DestinationPath .\NetLockAgent
.\NetLockAgent\NetLock_RMM_Agent_Installer.exe

For silent, unattended deployment via GPO, Intune, or Ansible, add flags:

.\NetLock_RMM_Agent_Installer.exe --hidden --no-log

• --hidden / -h — hide the console window (Windows only).
• --no-log / --nolog — delete installer logs after completion.
• --temp <path> / -t <path> — use a custom temporary directory.

Linux / macOS (Bash, with sudo):

unzip NetLockAgent.zip -d NetLockAgent
chmod +x NetLockAgent/NetLock_RMM_Agent_Installer
sudo ./NetLockAgent/NetLock_RMM_Agent_Installer

With no arguments the installer uses its embedded config. For manual re-configuration or repair, the installer also accepts positional modes: clean "<path-to-server_config.json>" for a fresh install with an external config, fix "<path>" to repair while preserving the existing server config, and uninstall to remove the agent.

The installer registers the agent as a background service (Windows service, systemd on Linux, LaunchDaemon on macOS) and starts it. Within a minute or two the agent contacts the server.

Note: NetLock RMM does not ship native .msi, .deb, .rpm, or .pkg packages; a single binary is used across all distributions.

Back in the Console, the device does not appear in Devices yet — it appears in Unauthorized Devices instead, unless you chose pre-authorization in step 4's wizard. This is by design: an administrator must explicitly approve any agent that claims membership in a tenant, to prevent rogue or misconfigured agents from polluting your inventory.

Step 6 — Approve the unauthorized device

1. In the navigation, open Devices → Unauthorized Devices.
2. Locate the new entry. It shows the device's hostname, operating system, and the tenant / location / group the agent was configured for.
3. Select the entry and approve it. Optionally adjust the target group before approval if the agent was configured against the wrong one.
4. Give the new device a human-readable label using the Edit Label dialog — for example MARKETING-LAPTOP-01 becomes Anna's laptop.

The device now appears in the main Devices list and reports status in real time. See Chapter 3 for the full Devices reference.

Step 7 — Create a policy and route it with an automation

With the device authorised, give it a policy. This takes two pieces in NetLock RMM: the policy itself (what should be enforced), and an automation rule that routes the policy to the right devices.

7a — Create the policy

1. Open Policies from the navigation.
2. On Manage Policies, click Add. Enter a name and description — for example Starter Workstations. Save.
3. Click Manage on the new row to open Policy Settings.
4. The default settings enforce the agent configuration but do not yet configure Antivirus, Application Control, Patch Management, or any other opt-in feature. Feel free to set your first settings. On a later stage you can edit the policy again to activate specific sensors or jobs.
5. Save.

7b — Route the policy with an automation

1. Open Automations from the navigation.
2. Click Add. Fill in:
   • Name and Description.
   • Condition — choose Group.
   • Expected result — enter the exact name of the group you created in step 3, for example Workstations.
   • Trigger (policy) — select Starter Workstations.
3. Save.

The server immediately re-evaluates every connected device against the new automation and pushes the matching policy. Within the agent's next poll interval the policy lands on the device.

Note: NetLock RMM evaluates automations in priority order and picks the first match. If you create multiple automations that could all match a device, order matters.

See Chapter 6 for the full Policies reference, Chapter 5 for the Automations reference, and Guide H.4 for a step-by-step walk-through.

Step 8 — Verify the policy arrived

Finally, confirm the pipeline worked:

1. Open Devices -> Authorized from the navigation.
2. The column called Policy indicates what policy is currently assigned to the device.

If the expected policy is not displayed there, check your automations order.

Or see Troubleshooting for deeper diagnostics.

What you have now

At the end of this walkthrough you have:

• A tenant with one location and at least one group.
• One managed device, labelled and approved.
• A policy attached to the group.

That is the smallest meaningful deployment of NetLock RMM. Everything else — automations, patch management, scripts, reporting — layers on top of this foundation. The next chapter, Navigating the Console, describes the UI you will spend the rest of your time in.

Navigating the Console

The Console has a consistent layout across every page. Learning where the fixed elements live — the navigation menu, the tenant selector, the theme toggle, the help dialog — means you can find any feature in a few clicks. This chapter is the short tour.

The overall layout

Every page shares the same shell:

• A header along the top with the product logo, the tenant / location / group selector, the theme toggle, and access to your profile and help.
• A left-hand navigation menu grouping every feature area the product exposes.
• A main content area to the right, where the currently opened page renders.
• A footer with product and build information.

You can resize the navigation, and the Console remembers your preference. The header remains visible on every page.

The navigation menu

The navigation menu on the left is built dynamically: the items you see depend on your permissions, the modules enabled on the deployment, and the order you chose to display them in. Two users with different permission sets on the same deployment will see different menus.

The default top-level groups, in their default order, are:

1. Dashboard
2. Devices Quick Access — with All Devices, Unauthorized Devices, and Device World Map sub-items.
3. Tenants
4. Automations
5. Policies
6. Patch Management
7. Collections — Scripts, Jobs, Sensors, Custom Fields, App Hub, Application Control, Device Control, Software Deployment.
8. File Server & Monitoring — File Server, Relay Server, Website Uptime, Port Scanner.
9. Tickets (only if the Ticket System is enabled)
10. Reports
11. Management — Events, Audit, Users.
12. Settings — 16 sub-pages covering administration.

Each group expands to reveal its sub-pages. Selecting a sub-page loads it into the main content area.

Note: Menu visibility is gated by roughly twenty permission flags at the top level, plus additional flags per sub-page. See the Permission reference appendix.

Customising menu order

The Console stores a per-user menu order in your account — the default order is the one listed above, and the server loads your personal order on every login. You can edit the order under /home.

The "Go Pro" upgrade button

If the deployment is unlicensed, a gold Go Pro button appears prominently in the navigation. Clicking it opens the upgrade / licensing flow. Once the deployment is licensed, the button disappears.

The tenant selector

Many pages — Tenant Settings, Location Settings, the Devices page, most Collections pages — act on a currently selected tenant, location, and group. The selector in the header is how you pick them.

1. Click the selector in the header to open a tenant / location / group picker.
2. Choose the tenant, then narrow to a specific location or group if desired.
3. The selection persists across the session and is used by every context-sensitive page you open afterwards.

A few pages also show the selected context inline near the top of the content area, so you always know what you are acting on.

Tip: If a page says "no tenant selected" or shows an empty state unexpectedly, open the header selector first and pick a tenant.

Dark mode

A theme toggle in the header switches between light and dark mode. Your preference is stored in your user account, so the theme is consistent across devices and sessions.

If the deployment has been whitelabeled (see A.6 Whitelabeling & themes), the brand colours apply in both modes. Custom community themes imported via the whitelabeling settings also respect the light/dark split.

Help and support

Help is available from the header via the in-app support dialog.

• Contact support — an in-app form for contacting our support team.
• Update available — appears when a new Console or server version is available, with a short summary and a link to the update flow.
• Subscription reminder — surfaces subscription renewal information on deployments that require it.

For deeper issues, the Troubleshooting appendix enumerates the common failure modes with diagnostics.

Notifications and toasts

Short-lived status messages appear as toast notifications in a corner of the screen — for example "Policy saved" after saving a policy, or an error after a failed bulk action. Toasts disappear after a few seconds; for historical records, check Events or Audit.

Real-time Console features (device status, script execution results, policy deployment feedback) use a persistent connection to the server. If toasts or status indicators stop updating, refresh the page to re-establish the connection.

Keyboard shortcuts

The Console does not define global keyboard shortcuts. There is no product-wide dark-mode toggle, command palette, or save/close binding. Keyboard handling is limited to page-local conveniences — for example, pressing Enter submits the login form, and the remote control window binds function keys relevant to that session. Each per-page shortcut is noted in the chapter that documents that page.

Where to go next

You now know the shell of the Console. From here, jump to whichever feature area matters most:

• Chapter 2 — Dashboard — the default landing page for most users.
• Chapter 3 — Devices — inventory, approvals, remote access.
• Chapter 4 — Tenants, Locations & Groups — managing the hierarchy.
• Part III — How-To Guides — task-oriented walkthroughs.

Dashboard

The Dashboard is the default landing page for most users. It is a grid of panels — configurable widgets — that display information from the Console's database: device counts, sensor values, event slices, and anything else you can express as a SQL query. Each user can create multiple dashboards, each with its own set of panels, and arrange them in an explicit layout mode.

Requires permission: the dashboard must be enabled for your user. A user without this permission does not see the Dashboard menu entry.

Overview

The Dashboard page sits at /dashboard. At the top is a bar of dashboards you have created; the active dashboard shows below it as a grid of panels. Dialogs handle creating and deleting dashboards and adding or configuring panels.

The first-run Setup Wizard

The first time a newly provisioned administrator opens the Dashboard, the Setup Wizard opens automatically. It walks through the minimum configuration needed to make the product useful — creating a first tenant, location, and group, and optionally downloading an agent installer. See First-Run Walkthrough for the full sequence.

You can close the wizard and reopen it from the help area later. If your environment is already set up, dismiss it and proceed directly to the empty dashboard.

Creating a dashboard

A fresh user starts with one empty default dashboard. You can create more so that different roles or different periods of the day get their own view (for example a "morning triage" dashboard and a "server health" dashboard).

1. Click the add button in the dashboard bar to open the Add Dashboard dialog.
2. Enter a name in the dashboard bar.
3. Save. The new dashboard is active and empty, ready for panels.

Dashboards are per-user. Two users do not share each other's dashboards unless an administrator configures defaults (see A.12 Content defaults).

Deleting a dashboard

1. Open the dashboard you want to remove.
2. Use the delete action to open the Delete Dashboard confirmation.
3. Confirm. The dashboard is removed immediately along with all panels it contains.

Warning: Deleting a dashboard cannot be undone. The panels you configured are lost. Recreate them from the Panel Builder if necessary.

Adding and configuring panels

Panels are the individual widgets that make up a dashboard. Use the Panel Builder to add or reconfigure them.

1. On the active dashboard, click the add-panel affordance.
2. The Panel Builder opens.
3. Choose a panel type: chart or table. For chart, also pick a chart sub-type: bar, line, area, pie, doughnut, or radar.
4. Build the data query. The Panel Builder exposes a SQL query builder with:
   • aggregate functions COUNT, SUM, AVG, MIN, MAX, and DISTINCT;
   • filter operators =, !=, <, >, <=, >=, LIKE, NOT LIKE, IS NULL, IS NOT NULL;
   • joins INNER JOIN, LEFT JOIN, RIGHT JOIN;
   • ORDER BY direction ASC or DESC.
5. For chart panels, configure the label column and value column that map the query rows onto the chart axes or slices.
6. Configure display settings — colours, legend position, legend visibility, axis labels, fill (area / line), line tension (line / area).
7. Configure the panel size in the dashboard grid: Width in grid columns (1-12) and Height in pixels (200-1200).
8. Save. The panel appears on the dashboard and renders from its query.

Panel types at a glance

Rearranging panels

Panels are laid out in a responsive grid. To reposition or resize them:

1. Click Edit Layout in the dashboard header to enter layout mode.
2. Adjust each panel's width (1-12 columns) and height (200-1200 pixels) using the inline numeric fields that appear on every panel.
3. Click Exit Layout Mode to save the layout.

Layout is stored per-user per-dashboard; your layout does not change what other users see on their own dashboards.

Common tasks

Set up a tenant-overview dashboard for an MSP

1. Create a new dashboard named after the tenant.
2. Add a device-count panel scoped to that tenant.
3. Add an event feed panel filtered to that tenant's devices.
4. Optionally add sensor panels for critical devices (a file server's disk usage, a domain controller's CPU).
5. Switch between per-tenant dashboards via the dashboard bar as you move through your queue.

Build a quiet "watch list" dashboard

1. Create a dashboard named Watch list.
2. Add quick-access panels that link to the specific devices you are currently watching after a policy rollout or software deployment.
3. Add an event feed filtered to the same devices.
4. Remove the dashboard when the watch window ends.

Reset a cluttered dashboard

If a dashboard has grown unwieldy, the simplest path is to create a fresh one from scratch and delete the old one. Panels are cheap to recreate with the Panel Builder, and the fresh start forces you to keep only the panels you actually use.

Permissions and conditional behaviour

• Access to the Dashboard is gated by a user-level permission. Users without it do not see the page or the menu entry.
• The panels you can add depend on the data you are permitted to see. For example, a user scoped to a single tenant will only see that tenant's devices in a device-count panel, regardless of how the panel is configured.
• The Setup Wizard is only shown on the administrator's first visit to the Dashboard and can be dismissed.

Related chapters

• Devices — what device-count and device-list panels reference.
• Sensors under Collections — the source of sensor panels.
• Events & Audit — the source of event feed panels.
• A.12 Content defaults — configure system-wide default dashboards.

Managing Devices

The Devices section is where most day-to-day RMM work happens. It covers the inventory of managed devices, the queue of agents waiting to be approved, device detail views with status and events, bulk operations such as reboot or shell commands, remote desktop sessions, and a world map showing where your devices are located geographically.

The section is exposed as a top-level menu group with three sub-pages:

All three pages respect the currently selected tenant, location, and group context from the header selector. See Navigating the Console for how the context works.

3.1 Device inventory, filters, and labels

The Devices page lists every authorized device for the selected tenant / location / group. Each row shows status, identifying information, and quick-action affordances.

Status indicators

Each device reports status in real time:

• Online — the agent is currently connected to the server.
• Online + Remote connected (pulsing) — the agent is currently connected to the server and has a remote connection established
• Offline — the agent has not checked in within the expected interval.

Status changes appear without a page refresh (the page uses the Console's real-time update channel). If status updates stop arriving, a page reload re-establishes the connection.

Filtering and searching

The Devices list offers two filter controls: a free-text search box and an online-only toggle.

The search box performs a case-insensitive contains match across 13 fields at once — enter any substring and rows where any of the following fields contains it remain visible:

• device name and label
• tenant, location, and group name
• agent version and last-access timestamp
• IP address, operating system, and domain
• antivirus solution and firewall status
• last active user

The online-only toggle, when enabled, restricts the list to devices whose status is currently Online + Remote connected. Combined with a search term, it narrows the list to online devices matching the search text.

Labels

Every device can carry a human-readable label. Rename it to something meaningful (Anna's laptop, Warehouse POS 3) using the Edit_Label dialog.

1. Select the device in the list.
2. Right click the label and open Edit_Label.
3. Enter the new label and save.

Tenant / location / group assignment

Every device belongs to exactly one group, in exactly one location, in exactly one tenant. To move a device between groups, use the group assignment affordance on the device. Moving a device may change which policy it receives, because policy assignment is driven by Automations that match on device attributes such as group name. Expect policy changes to land within the device's sync interval.

3.2 Unauthorized devices and the approval flow

An agent that successfully contacts the server but has not yet been approved appears in Unauthorized Devices, not in the main Devices list. This intermediate state prevents rogue or misconfigured agents from silently polluting your inventory.

The approval flow is:

1. The agent is installed on a device with configuration that targets a specific tenant / location / group.
2. The agent contacts the server and registers as unauthorized.
3. An administrator reviews the entry in /unauthorized_devices — confirm the hostname, operating system, and the target tenant / location / group are correct.
4. Adjust the target group if needed.
5. Approve the entry. The device is created in the authorized inventory and begins receiving policies and automations.
6. Optionally set a label immediately after approval using the Edit_Label dialog.

Rejecting an unauthorized device removes it from the queue; the agent will re-register on its next poll and reappear unless you block it at the network or agent level.

See the First-Run Walkthrough for a full end-to-end example, and Guide H.2 for a task-focused recipe.

3.3 Device detail view

Selecting a device in the list opens its detail view. The detail view pulls everything the Console knows about the device into one place:

• Identifying information — hostname, label, tenant / location / group assignment, operating system, last-seen timestamp, IP addresses reported by the agent.
• Status — current online / offline / error state, and the agent version.
• Custom fields — values for every custom field defined in Collections, editable per device.
• Events — recent operational events scoped to this device; a link into the full Events page is available.
• Policy — the single policy currently assigned to the device (or no_assigned_policy_found if no automation matched). See Chapter 5 — Automations for how assignment works.
• Actions — per-device operations: remote control, remote shell, file browser, registry editor, event log viewer, service manager, wake-on-LAN, uninstall application, SNMP tools, and the bulk affordances covered in 3.4 and 3.5.

The per-device actions are implemented as the dialog set below. Each dialog targets the currently selected device (or the set selected for bulk actions):

The exact availability of some dialogs depends on the device's operating system — for example the Registry Editor is Windows-only, and the Linux / macOS Service Editor applies only to Linux and macOS devices.

Editing custom fields on a device

1. Open the device detail view.
2. Scroll to the custom fields area.
3. Edit the value inline, or open the custom-field editor for richer types (for example a date picker).
4. Save. The new value is recorded and visible in reports and panels that reference the field.

Defining which custom fields exist happens at the Collections level; see Chapter 8 — Custom Fields.

Viewing per-device events

The detail view shows a tailored slice of the Events feed: only events concerning this device. This is usually where you go first to diagnose why an action did not land — a policy deployment that silently failed, a script that did not run, a sensor that went silent.

For the full events reference, see Chapter 12.

3.4 Bulk actions

Rather than operating on devices one at a time, the Devices page supports selecting many devices and issuing a single operation against all of them. Common bulk actions include:

• Bulk remote shell — execute a command on every selected device and collect the results.

The bulk remote shell flow uses two dialogs:

• Bulk Remote Shell — pick the command to run, confirm the target set, and launch.
• Bulk Remote Shell Results — display per-device results as they arrive, including stdout, stderr, and exit status.

Warning: Bulk actions run on every selected device without further per-device confirmation. Double-check the selection before you launch a bulk reboot on a production fleet.

Tip: For repeatable work, save the command as a script in Collections and invoke the script rather than typing the command every time.

3.5 Remote control and remote shell

Individual devices support remote access via the Console:

• Remote shell — an fire and forget shell session on the device (PowerShell on Windows, Bash or the default shell on Linux and macOS), opened from the Remote Shell dialog. Command history for the device is available from the Shell History dialog.
• Real-Time Remote shell — an interactive shell session on the device (PowerShell on Windows, Bash or the default shell on Linux and macOS), opened from the Remote Shell dialog. Command history for the device is available from the Shell History dialog.
• Remote control — a graphical remote-control session to the device's desktop, opened from the Remote Control window.

How remote control works

NetLock RMM does not use VNC or RDP for remote control. Instead it streams the device's screen over its own protocol using one of two video encodings:

• H.264 — hardware-accelerated on the device's GPU when available, with a CPU software encoder as fallback. H.264 is the default when the agent and relay can negotiate it.
• JPEG polling — used when H.264 is not available (for example when the H.264 slot on the relay is already in use), and also the mode used by the legacy transport.

The Remote Control window exposes a connection-mode dropdown with two options:

• Relay (Recommended - faster) — the session is routed through a dedicated Relay Endpoint that sits between the Console and the agent. This is the fast, modern path and is always preferred when the relay is configured.
• SignalR (Legacy - fallback) — the session is routed through the Console's own SignalR hub on the main server. This path is slower and always uses JPEG polling.

Selection is explicit: you pick the mode before starting the session. The Relay path auto-falls-back to JPEG if the relay's single H.264 slot is already occupied, and to SignalR + JPEG if the relay cannot be reached at all.

See Chapter 9 — Relay Server for how to deploy and manage the Relay App, and A.7 Remote screen control for authentication and default-settings reference.

3.6 The Device World Map

The Device_World_Map page at /device-world-map visualises your fleet geographically. Each device is plotted on a world map based on IP-geolocation data captured when it reports to the server.

Use cases include:

• Confirming a device claims to be where you expect it to be (an unexpected pin in another country is a useful signal).
• Assessing the impact of a regional issue — for example, how many devices are on a specific coast during a power event.
• Communicating fleet spread to non-technical stakeholders in a single screenshot.

The map respects your tenant / location / group context: selecting a tenant in the header narrows the map to that tenant's devices only.

Note: Map accuracy depends entirely on the quality of IP geolocation for the device's external IP. Devices behind a VPN will appear at the VPN exit rather than the physical device location. The IP lookup happens locally on your NetLock RMM server. IP lookups are never communicated to the outside world.

Permissions

Device-related permissions follow the standard pattern:

• A top-level permission enables the Devices section.
• Per-action permissions gate bulk actions, remote shell, remote desktop, approvals, and label editing.
• Tenant-scoped users only see devices in tenants they have access to.

See the Permission reference for the full list.

Related chapters

• Chapter 4 — Tenants, Locations & Groups — the hierarchy devices live in.
• Chapter 6 — Policies — how policies flow to devices.
• Chapter 8 — Collections — scripts, sensors, and custom fields that extend what a device exposes.
• Chapter 9 — File Server & Monitoring — relay-mediated remote access.
• Chapter 12 — Events & Audit — per-device event and audit records.

Tenants, Locations & Groups

NetLock RMM organises every managed device into a three-level hierarchy: tenant, location, group. This chapter is the canonical reference for creating and managing that hierarchy. The hierarchy drives how policies, automations, and permissions are scoped, so getting it right early pays off for the life of the deployment.

4.1 The hierarchy, in brief

A quick refresher from Core Concepts:

• A tenant is the top-level organisational container. For an in-house IT team this usually maps to the company; for an MSP it maps to a customer.
• A location is a subdivision of a tenant — typically a physical site or office.
• A group is a subdivision of a location — typically reflecting how devices should be configured (Workstations, Servers, Laptops) rather than where they physically sit.

Every device belongs to exactly one group. Configuration — policies, automations, scripts — can be applied at any level and flows down: a policy on a tenant applies to every device in every location and every group of that tenant.

Tip: Keep groups focused on configuration intent. If a single policy applies to every device regardless of site, one group per location is plenty. If policies differ by device type, create device-type groups inside each location.

4.2 Managing tenants

The Manage Tenants page at /tenants is the entry point. It lists every tenant you have permission to see, along with summary information (device counts, last activity).

Creating a tenant

1. Open Tenants from the navigation.
2. Click the add affordance on the Manage Tenants page.
3. Fill in the tenant name and any additional details required by your deployment.
4. Save.

The newly created tenant starts empty — no locations, no groups, no devices.

Editing a tenant

Select a tenant in the list to enter its detail view. From there you can rename it, change its contact information, or adjust tenant-wide settings (covered in 4.3). Editing a tenant does not affect its devices or their assignments; only the tenant metadata changes.

Deleting a tenant

Deleting a tenant is rare but supported. Before deleting, confirm:

• The tenant has no active devices you still care about.
• No reports, scheduled deliveries, or automations reference the tenant.
• You have archived any customer data you may need later — device inventory from the Devices page, events from Events & Audit, and any reports from Reports. (The tenant-list export at 4.5 only captures tenant metadata, not the data under the tenant.)

4.3 Tenant settings

Tenant-level configuration lives on the Tenant Settings page at /tenant_settings. The page requires a tenant to be selected in the header context; if none is selected, choose one first.

The page has a flat layout with three sections:

• General Information — editable fields for the tenant's name, company, and description. This is the metadata the rest of the Console refers back to (the name shown in reports, in exports, in the navigation selector).
• Contact Persons — five contact-person slots with editable details. These are used as recipients and fallback contacts for tenant-scoped notifications and reports.
• Locations — a searchable table listing every location under this tenant, with a Manage affordance on each row that opens the location's detail view (see 4.4). You can add a new location directly from this table.

There are no separate tabs for branding, notifications, integrations, or agent configuration on the Tenant Settings page. Those concerns live elsewhere:

• Branding and themes: deployment-wide in A.6 Whitelabeling & themes.
• Notification channels and recipients: deployment-wide in A.8 Notifications deep dive.
• Agent configuration: per-installer in the Agent Download wizard, not a global tenant setting.

Per-tenant isolation

Tenant metadata and contact persons are isolated per tenant: editing them in one tenant has no effect on another. For system-wide defaults that populate new tenant records, see A.12 Content defaults.

4.4 Locations and groups

With a tenant in place, add locations and groups beneath it.

Adding a location

1. Open the tenant and navigate to Location Settings (route /location_management/*/location_settings).
2. Use the add-location affordance.
3. Enter a location name that reflects the site — Berlin HQ, Remote Workers, Datacenter A.
4. Save.

Locations are freeform; use as many as the geography of your deployment warrants. An MSP managing a customer with three offices typically creates three locations.

Editing and deleting a location

Standard edit and delete affordances apply. Deleting a location removes its groups; any devices in those groups lose their group assignment and must be reassigned before configuration flows to them again.

Adding a group

1. Open the parent location in Location Settings.
2. Use the add-group affordance.
3. Enter a group name aligned to the devices it will contain.
4. Save.

Groups accept devices immediately. You can now:

• Configure agent installers to target this group (see First-Run Walkthrough step 4).
• Move existing devices into the group from the Devices page.
• Route policies to the group by creating an Automation whose condition is Group and expected value is this group's name.

Moving devices between groups

Use the device-group assignment affordance on the device in the Devices page (see Chapter 3). The agent picks up the new assignment on its next poll and any policies attached to the new group take effect.

Note: Moving a device between groups does not trigger a device reboot or re-authorisation. The agent simply starts receiving a different policy set.

4.5 Exporting the tenant list

The Export Data dialog, opened from the Manage Tenants page, exports the list of tenants you are permitted to see. The scope and contents are narrow: it is not a full tenant archive.

What is exported. One row per tenant, with these fields: id, tenant_name, guid, date (creation date), author (who created the record), description, and company. Devices, policies, events, audit entries, custom-field values, and deployment histories are not part of this export — those live in their own chapters and are exported from there if needed.

Scope. Every tenant that matches your tenants permission list. If you are scoped to specific tenants, the export contains only those. There is no single-tenant-only mode; the dialog always exports the full visible list.

Formats. The dialog asks you to pick one output format:

• JSON
• XLSX (spreadsheet)
• XML
• HTML

Permissions. Any user with access to the Manage Tenants page can run the export. There is no separate export permission flag.

Steps:

1. Open Manage Tenants.
2. Click the export action to open the Export Data dialog.
3. Pick the output format and confirm. The file downloads to your browser immediately — the export runs synchronously, not as a background job.

If you need to archive more than the tenant list — for example a customer's full device inventory or audit trail before offboarding — run the relevant exports from Reports, Events & Audit, or use the export affordances on the specific pages for that data.

Common tasks

Set up a new MSP customer from scratch

1. Create a tenant for the customer on Manage Tenants.
2. Add one location per physical site the customer operates.
3. Add groups inside each location that reflect the device roles you will manage (Workstations, Servers, etc.).
4. Open Tenant Settings and fill in contact information and any per-tenant defaults.
5. Generate an agent installer targeted at the intended starter group (see First-Run Walkthrough).
6. Deploy the agent on the first device and approve it in Unauthorized Devices.
7. Build and apply a baseline policy to the group (see Guide H.4).

Reorganise an existing tenant

1. Plan the new structure on paper first — list the new locations and groups and the automations that will route policies to each group.
2. Create the new locations and groups in Location Settings.
3. Create or update Automations to match the new group names before moving devices, so devices do not sit unassigned after the move.
4. Move devices in small batches, verifying policy assignment in the device detail view and policy deployment in Events after each batch.
5. Delete the old locations and groups once empty.

Archive and remove a departing customer

1. Export device inventory, event history, and any scheduled reports from their respective pages — the tenant-list export only covers tenant metadata.
2. Optionally export the tenant list via the Export Data dialog on Manage Tenants so you keep a record of the tenant row itself.
3. Uninstall agents on the customer's devices (outside the scope of this chapter).
4. Delete the tenant from Manage Tenants.

Permissions

Tenant, location, and group operations are gated by a tenant-management permission group. In addition, tenant-scoped user accounts (see Chapter 14 — Users & Roles) only see the tenants they are explicitly permitted to access, which has the side effect of restricting every other feature area to those tenants as well.

Related chapters

• Core Concepts — the tenant → location → group model in context.
• Chapter 3 — Devices — how devices are created, moved, and labelled.
• Chapter 6 — Policies — attaching policies to tenants, locations, and groups.
• Chapter 14 — Users & Roles — scoping user access to specific tenants.
• A.12 Content defaults — system-wide defaults that apply to new tenants.

Automations

Automations in NetLock RMM are a narrow, purpose-built feature. They are not a workflow engine, not a job scheduler, and not an event-action pipeline. Their one and only job is to decide which policy a device receives. If you have used other RMM products, set aside any expectation that "automation" means trigger-driven scripts, ticket creation, or multi-step workflows — in NetLock RMM those responsibilities live elsewhere, and this chapter explains where.

5.1 What an automation is

An automation is a single rule of the form:

IF a device's <attribute> matches <expected value>  THEN  assign policy <name>

Each rule has exactly three pieces of configuration: a condition type (which attribute of the device to compare), an expected value (either a string the attribute must equal, or — for the entity-picker conditions — the specific tenant, location, group, or device the rule targets), and a target policy (the policy to assign when the rule matches). There is no second step, no action chain, and no side effect beyond setting the device's assigned policy.

Note: A policy on its own is inert. Devices only receive configuration when an automation's condition matches them and points to a policy. If no automation matches a device, the device has no policy and the Console shows no_assigned_policy_found on its detail view.

Automations are managed on the Manage Automations page at /automations.

5.2 The seven condition types

The condition dropdown exposes seven mutually exclusive options. Each rule picks one. Four of them target an internal entity that you pick from a list (the rule stores the entity's identity, not its display name); the remaining three compare against a string you type.

Entity-picker conditions (Device Name, Tenant, Location, Group) are immune to renaming. If you rename the tenant Acme to Acme Corp, every rule that targets it keeps working — the rule does not store the name. Conversely, deleting the picked entity orphans the rule.

String-match conditions (Internal IP-Address, External IP-Address, Domain) compare the device's reported value to the Expected result you type, after both sides are trimmed of surrounding whitespace and lower-cased. For the IP conditions, an ::ffff: IPv4-mapped IPv6 prefix is also stripped before comparison, so a device reporting ::ffff:10.0.0.5 matches a rule expecting 10.0.0.5. There is no wildcard, no regex, and no CIDR or range matching — if you need multiple values, create one rule per value.

Tip: Because the comparison is case-insensitive and whitespace-tolerant, you do not need to worry about how the agent capitalizes the domain name or whether the IP literal has a trailing space. You do still need an exact match on the rest of the string.

5.3 How a rule is resolved

When a device syncs with the server, the server walks the automation ruleset in a fixed order determined by condition type, not by any list position you control. Within each condition type, the earliest-created rule wins. The first rule that matches the device determines the policy, and evaluation stops.

5.3.1 Condition-type evaluation order

The server tries the seven condition types in this exact order. As soon as a rule matches, the device receives that rule's target policy and no further conditions are checked:

1. Device Name — matches the specific device the rule targets.
2. Internal IP-Address — matches the device's reported LAN IP.
3. External IP-Address — matches the public IP the device appears from.
4. Domain — matches the device's reported Windows or DNS domain. Skipped when the device reports no domain.
5. Group — matches the group the device belongs to. Skipped when the device is not in a group.
6. Location — matches the location the device belongs to. Skipped when the device is not assigned to a location.
7. Tenant — matches the tenant the device belongs to. Skipped when the device is not assigned to a tenant.

This ordering is built into the product. It cannot be configured, reordered, or overridden.

5.3.2 Tie-breaking inside a condition type

If you have more than one rule of the same condition type, the rule that was created first wins. The server processes them in creation order and stops at the first match. There is no list-position knob and no "move up / move down" affordance on the Console.

5.3.3 Practical consequences

• Specific beats general by construction. Because Device Name is evaluated before everything else, pinning one machine to one policy always wins over a group, location, or tenant rule that would otherwise match. You do not arrange this — the order is intrinsic.
• The four network/entity tiers form a natural fallback ladder. Group is evaluated before Location, which is evaluated before Tenant. A device that has both a group rule and a tenant rule gets the group rule; the tenant rule acts as a catchall for devices in that tenant whose group is not separately routed.
• String conditions outrank entity conditions. Internal IP, External IP, and Domain all run before Group, Location, and Tenant. A laptop on the office LAN can be steered to a different policy than the same laptop's group rule would assign, simply by adding an internal-IP rule.
• Overlap is allowed but not merged. If two rules both match, only the one reached first by the evaluation order applies. Policies never layer or combine.
• A device is assigned at most one policy at a time. See Chapter 6.
• No match is a valid outcome. A device that matches no rule runs without a policy. The server does not invent one and the device shows no_assigned_policy_found on its detail view.

Note: Because tie-breaking is based on the rule's internal creation order, you cannot promote a newer same-type rule above an older one from the Console. If two rules of the same condition type both match a device and the wrong one is winning, delete the older rule and recreate it — or change one of the two rules to use a more specific condition type higher up the evaluation order.

5.4 Creating, editing, and deleting a rule

Use the three dialogs on the Manage Automations page:

• Add Automation — opened from the add affordance. Fields: Name, Description, category (currently always policy), Condition, Expected result, and the target policy. For the three string-match conditions (Internal IP-Address, External IP-Address, Domain), Expected result is a text input. For the four entity-picker conditions (Device Name, Tenant, Location, Group), Expected result becomes a picker for that entity.
• Edit Automation — opened from a row's edit action. Pre-populated with the rule's current values.
• Delete Automation — opened from a row's delete action. Confirmation only.

When AI is enabled in Settings → AI/LLM, both Add and Edit dialogs expose an AI Assistant button that can propose a rule from a natural-language description. The AI only writes into the dialog's fields; it does not save the rule for you.

Note: Adding, editing, or deleting any automation triggers an immediate re-sync of every connected device. Devices do not wait for their next scheduled poll to re-evaluate policy assignment — the change lands right away.

Note: There is no field on this dialog that controls evaluation order. Evaluation order is determined by the condition type you choose (see §5.3) and, within a condition type, by which rule was created first.

5.5 What Automations explicitly cannot do

If you are coming from another RMM, the following list is important. None of these are supported by the Automations feature:

• No event triggers. You cannot configure "when a disk fills up, run this".
• No schedule triggers. You cannot configure "every Sunday at 02:00, do X".
• No webhook or API triggers. External systems cannot kick off an automation.
• No manual triggers. There is no "Run now" button on a rule.
• No script action. Automations never execute a script.
• No notification action. Automations never send an email, Teams message, Telegram message, or webhook.
• No ticket action. Automations never open a ticket.
• No chained steps. One rule has one condition and one outcome — the target policy.
• No scope selector per rule. A rule evaluates against every device; scoping is encoded in the condition (for example Tenant = Acme).
• No execution log. There is no per-automation history view. Policy changes that result from rule evaluation are recorded in general Events (see Chapter 12) and reflected in the device detail panel's Assigned policy field.

5.6 Where event-driven and scheduled work actually lives

Because Automations only route policies, every other "when X happens, do Y" pattern is served by a different feature. The three you will reach for most often:

• Sensors (see Chapter 8.3) are the right tool when you want the agent to watch a metric and react. A sensor samples its category on a schedule, raises a notification when the notification threshold is crossed, and runs an action script when the action threshold is crossed. This is how you express "when CPU exceeds 90% for five samples, run a cleanup script".
• Jobs (see Chapter 8.2) are the right tool when you want a script to run on a device on a timetable. A job picks a script and assigns it one of the twelve supported schedules (boot, one-shot date, recurring interval, recurring on specific weekdays, and so on). This is how you express "every Friday at 18:00, rotate the backup script".
• Patch Management handles the "install approved patches on a schedule" case without any automation glue — see Chapter 7 for the approval queue and Chapter 6.12 for the per-policy rollout rules.

Automations compose none of these. They do not call a sensor, queue a job, or trigger a deployment. They only decide the policy a device runs under — which in turn can include jobs, sensors, and patch rules — but the composition is always "automation assigns policy; policy contains everything else".

5.7 Worked example — a three-tenant MSP

Consider an MSP managing three tenants, each with a small office and a mix of workstations and servers. A reasonable, minimal automation set looks like this, grouped by condition type so the evaluation order is visible at a glance:

Tier 1 — Device Name (pin specific machines):

Tier 5 — Group (the main routing layer):

Tier 7 — Tenant (per-tenant fallback):

How this resolves in practice:

• ACME-DC01 syncs. The server starts at Device Name, finds the pin, assigns Acme Domain Controller, and stops. The group and tenant rules below are never reached for this device.
• A new workstation joins Acme / Berlin / Workstations. No Device Name rule matches. No IP or domain rule is configured, so those tiers are empty. At Group, the rule for Acme / Berlin / Workstations matches; the device receives Acme Workstation Baseline.
• A workstation lands in tenant Acme but in a group that has no rule yet. The Group tier finds no match. The Location tier is empty. At Tenant, the Acme rule matches; the device receives Acme Fallback.
• A device outside all three tenants. No rule of any condition type matches. The device receives no policy and the Console shows no_assigned_policy_found. Adding a tenant for it is the fix.

Tip: Keep the Tenant fallback tier explicit. A tenant-level catchall rule is far easier to debug than a setup where some devices silently get no policy because no rule happened to match. The fallback also makes the tier ladder (Group → Tenant) visible.

Note: Within a tier — for example, between two Group rules — the rule created first wins. You do not get a list-position knob to change this. If two same-condition rules both apply to the same device, the cleanest fix is to make one of them more specific via a higher-tier condition (a Device Name pin, an Internal IP rule, and so on).

5.8 Editing a policy versus editing an automation

Two distinct edit points, two distinct outcomes:

• Editing a policy changes what every device already assigned to it will receive at next sync. The set of devices is unchanged.
• Editing an automation changes the set of devices a policy is routed to. Every connected device re-evaluates its assignment immediately.

You will rarely need to touch automations once the routing is stable. Day-to-day configuration changes happen inside the policies themselves (Chapter 6).

Permissions

Automations are gated by the following flags (see Chapter 14 and the Permission reference appendix):

• automation_enabled — master flag. A user without this flag does not see the Automations navigation entry and cannot reach /automations.
• automation_add — ability to create a new automation.
• automation_edit — ability to edit an existing automation.
• automation_delete — ability to delete an automation.

A user with automation_enabled but neither _add, _edit, nor _delete has read-only access — they can inspect the ruleset without changing routing.

Related chapters

• Core Concepts — the condition → policy model in the wider vocabulary.
• Chapter 4 — Tenants, Locations & Groups — the attributes most automations match against.
• Chapter 6 — Policies — what the target policy actually controls.
• Chapter 8 — Collections — Sensors and Jobs, where event-driven and scheduled work live.
• Chapter 12 — Events & Audit — where policy changes resulting from automation evaluation are recorded.

Policies

A policy is the central configuration unit in NetLock RMM. Almost every feature you can tune on a device — antivirus behaviour, firewall rules, remote-access capabilities, tray branding, patch rollout, scheduled jobs, monitoring sensors — lives inside a policy. This chapter is the reference for the policy object, the Policies list page, and every tab of the Policy Settings editor.

6.1 What a policy is

A policy is a named bundle of device configuration. The single bundle covers:

• Agent behaviour (sync interval, auto-update, remote-control capabilities).
• Tray icon branding and visibility.
• Windows-specific controls (Microsoft Defender Antivirus, Application Control, USB Device Control).
• Linux-specific controls (UFW firewall).
• Sensors and Jobs attached to the policy.
• Patch Management rollout rules per platform.
• Which App Hub apps the tray icon exposes on devices under the policy.

A few rules about policies are load-bearing across the whole product and worth stating up front:

• A device is assigned at most one policy at a time. Policies do not layer, merge, or inherit. The agent runs the one policy assigned to it, or no policy at all.
• Policies do not attach to tenants, locations, groups, or devices directly. Every assignment flows through an automation — see Chapter 5. There is no "apply to group" affordance on the Policies page, the Groups page, or the Devices page.
• There are no policy templates. New policies start blank. The only way to seed a new policy from an existing one is to duplicate.
• There is no versioning, no change history, and no rollback. Edits apply in place. If you need a safety net, duplicate the policy first.
• The Author column is informational, not an ACL. It records who created the policy. Edit and delete access are gated by the policies_edit and policies_delete permission flags, not by authorship — any user with those flags can edit or delete any policy. Visibility of the row is gated by policies_enabled.

Tip: Treat the duplicate-before-editing habit as a convention. Because there is no rollback, a duplicated copy is your only path back from a bad change — and duplication takes about two clicks.

6.2 The Policies list page

The Manage Policies page at /policies lists every policy in the system. The table shows:

Actions on the page (toolbar above the table):

• Add opens the Add Policy dialog. Fields: Name, Description. Save creates a blank policy — every tab of the editor is at its default state.
• Manage navigates to the Policy Settings editor for the selected policy (/policy_settings). Duplicate and Delete actions live inside that editor, not on this list — see §6.3.
• Export (download icon) opens the export dialog. It exports the policy list — one row per policy, with the columns above — as JSON, XML, or HTML. This is a list export, not a full policy export; the contents of each policy's tabs are not included in the dump.

Note: The list page does not expose a Delete or Duplicate button. To delete or duplicate a policy you must open it via Manage first.

6.3 A tour of the Policy Settings editor

The Policy Settings editor at /policy_settings is a tabbed workspace. Eight top-level tabs cover the entire surface of what a policy can configure. Every tab is kept alive once opened, so you can switch between tabs and your in-progress edits are preserved until you save or navigate away.

Above the tab strip sits the editor toolbar:

• Back returns to the Manage Policies list without saving.
• Save (visible when policies_edit is granted) commits all in-progress edits across every tab in one go. Until you click Save, your changes are held in the editor's in-memory state and are lost on a hard reload.
• Duplicate (also policies_edit) opens the Duplicate Policy dialog. The dialog pre-fills the new name as <original> (Copy), which you can override; it then clones the policy as a new row. Duplication is the only "starting point from an existing policy" mechanism.
• Delete (requires policies_delete) opens the Delete Policy confirmation. Deletion cannot be undone. If any automation targets the deleted policy by name, devices matching that automation start reporting no_assigned_policy_found until the automation is updated.

Warning: Deleting a policy does not rewrite automations that reference it. Clean up automations before you delete a policy, or audit them afterwards.

TODO: Engineering review — the Duplicate flow does not copy the device_control_settings, linux_firewall_settings, or app_hub_settings columns in the current release. Confirm whether this is intentional; if not, document the omission.

The eight tabs:

1. Agent. General agent behaviour and remote-control capability toggles. Every policy touches this tab.
2. Tray Icon. End-user tray behaviour and branding. Applies to every device under the policy.
3. Windows. Windows-only features, grouped into three sub-sections — Microsoft Defender Antivirus, Application Control, USB Device Control. Settings in this tab have no effect on Linux or macOS devices.
4. Linux. Linux-only features — currently UFW firewall configuration.
5. Sensors. SNMP sensor configuration attached to the policy.
6. Jobs. Scheduled job definitions attached to the policy.
7. Patch Management. Per-platform rollout rules — Windows, Linux, macOS, Docker — each with its own sub-tabs for general settings, approval filtering, deployment rings, schedule, reboot, notifications, and retry.
8. App Hub. Catalogue curation — which apps from the global App Hub appear in the tray icon for devices under this policy.

Each tab is documented in its own section below.

6.4 Agent tab

The Agent tab controls the behaviour of the agent process itself. It has two sub-tabs: General and Remote Control.

General. Two knobs:

• Sync interval — how often the agent polls the server, in minutes. The allowed range is 5 to 1440 (one day). Short intervals keep the Console responsive to configuration changes; long intervals reduce server load for large fleets.
• Auto-update agent — whether the agent installs new agent versions when the server offers them. Leave this on in most environments; disable only when you need to pin devices to a specific agent build for testing.

Remote Control. A master toggle and a set of per-capability switches:

• Enable remote service — master switch for all remote operations on the device. Everything below is gated on this.
• Remote Shell — permits interactive shell sessions.
• File Browser — permits remote file transfer.
• Task Manager — permits remote process management.
• Service Manager — permits remote service start/stop/restart.
• Registry Editor (Windows only) — permits remote Windows registry editing.
• Event Log Viewer (Windows only) — permits remote Windows event log viewing.
• SNMP Tools — permits SNMP GET / Walk / Monitor operations from the Console.
• Remote Screen Control — permits remote screen sessions. Exposes an Access mode dropdown with two values:
  • Attended (user confirmation required & tray icon needs to be enabled!) — the on-device user must approve each session, and the tray icon must be enabled in §6.5 for the approval prompt to render.
  • Unattended (no user confirmation required) — the session starts without user interaction.

Note: Remote Screen Control uses H.264 or JPEG over Relay or SignalR; it is not VNC or RDP. See A.7 Remote screen control for the deployment-wide defaults.

Disable the individual capabilities for high-sensitivity devices where you want, for example, a remote shell but not file transfer.

6.5 Tray Icon tab

The Tray Icon tab shapes what end users see on their device. Branding here is per-policy — a single deployment can present different branding to different customers.

A master Enabled switch at the top of the tab gates everything below — if it is off, the tray icon does not run on devices under this policy.

General. A single field:

• Tray Icon Title — text shown in the tray window's title bar.

Buttons. Per-entry visibility for the built-in tray menu items:

• Show About Button — surfaces the About entry. When on, the About Button Title field sets the menu label.
• Show Exit Button — lets the user close the tray icon. When on, the Exit Button Title field sets the menu label. Hide the exit button for managed devices where the tray is mandatory.

App Hub. Controls whether the App Hub window is reachable from the tray, and customises the labels inside that window:

• Show App Hub in tray context menu — master toggle for the App Hub entry. The Context menu label sets the label shown in the right-click menu.
• App Hub window text overrides (all leave-blank-for-default):
  • Window title, Search placeholder, Refresh button, Install button, Update button, Uninstall button.

Note: This section only governs visibility and labels of the App Hub in the tray. The actual catalogue of apps offered to devices under this policy is curated in §6.13.

Logo & Icon. A single upload widget accepting PNG, ICO, or JPG up to 256 KB. The uploaded image replaces the default tray icon.

About Interface. Branding for the About window that opens from the tray's About button:

• Enable — master switch for the About window.
• Window Title, Title, Description — free-text fields shown to the user.
• Show Version, Show Copyright — toggles for the standard footer lines.
• Close Button Title — text on the dismiss button.

Chat interface. Branding for the AI Chat window that the tray exposes (see Chapter 13):

• Loading Message, Window Title, Subtitle — top-of-window text.
• Show Welcome Message + Welcome Message Text — optional greeting in the chat pane.
• Input Field Placeholder — placeholder text in the user input box.
• Enable Settings — exposes a settings menu inside the chat window, with sub-toggles Allow Export Chat History, Allow Copy Chat History, and Show About.

Remote Screen Control. Text shown to the on-device user when a remote screen session is requested or active:

• Request Title, Request Message, Accept Button Title, Decline Button Title — the approval dialog shown for attended sessions (see §6.4).
• Stop Button Title, Support Agent Connected Message — surfaced while a session is active so the user can end it.

Buttons (custom). A managed table of custom tray-menu entries. Each row has Name, Description, Author, Date, Action, Action details. Use Add, Edit, Delete to maintain entries; each entry adds one item to the right-click tray menu mapped to an action (script, URL, etc.).

Logos, icons, labels, and custom buttons are pushed to the agent at the next sync; they do not change mid-session for a user already logged in.

6.6 Windows tab — Microsoft Defender Antivirus

The Windows tab groups three Windows-only feature areas. The largest by far is Microsoft Defender Antivirus. This section walks through its two sub-tabs in full. The other two sub-sections are covered in 6.7 and 6.8.

At the top of the Configuration sub-tab sits a master Enabled switch. When it is off, every field on the Configuration and Notifications sub-tabs renders disabled — the Console still stores your configuration but the agent does not apply any of it. When it is on, the agent synchronises the settings below with Microsoft Defender on every sync interval.

6.6.1 Configuration sub-tab

The Configuration sub-tab is organised into four sections.

General Settings. Settings that do not fit the scanner-specific categories:

• User Interaction — Show Windows Security Center icon, Show Windows Security Center tray icon. Control whether end users see Defender's own Security Center surface.
• Updates — Check signatures hourly, Allow metered updates. The first forces hourly signature polling; the second lets signature downloads run over connections the operating system classifies as metered.
• Other — Delete quarantine older than 6 months. A retention switch for the Defender quarantine.

Scanner Settings. Behaviour for real-time and on-access scanning:

• Direction dropdown — Inbound & Outbound, Inbound, or Outbound. Scopes which traffic direction the network-aware parts of the scanner examine.
• File System — Hash computing, Block at first seen (permanently disabled in the UI in the current release), Scan archives, Scan emails. These toggles control the deep-scan behaviours most often tuned for performance.
• Network — Scan network files, Filter incoming connections, Datagram processing. Network-scanning knobs; most useful for servers.
• Parser — per-protocol toggles for TLS, RDP, SSH, HTTP, DNS, and DNS over TCP. Enable or disable Defender's parsing of each protocol.

Exclusions. A managed list of paths and process patterns the scanner skips.

The table has columns Exclusion, Type, Description, Date. Actions on the toolbar:

• Add opens the Add Exclusion dialog. Fields: Type (one of File, Directory, File Type (extension), or Process), the Exclusion value matching that type, and an optional Description.
• Edit opens the Edit Exclusion dialog, pre-populated.
• Delete removes the selected row.
• Export exports the exclusion list.

Exclusion types in detail:

• File — an exact file path.
• Directory — a folder path; everything under it is excluded.
• File Type (extension) — a file extension, for example .bak.
• Process — a running process image; files accessed by that process are excluded.

Scan Jobs. Scheduled on-demand scans.

The table columns: Status, Name, Date, Description, Schedule Type, Time, Monday through Sunday day toggles, Scan Mode, CPU Usage %, Scan on Battery, Network Drives, Removable Disks, Update Signatures.

Actions:

• Add opens the Add Scan Job dialog. You set: Enabled, Name, Description, schedule type, day-of-week toggles, time, scan mode, CPU-usage cap, and the battery / network / removable toggles.
• Edit opens the Edit Scan Job dialog, pre-populated.
• Delete removes the selected row.
• Export exports the scan-job list.

Each scan job targets a list of directories. Use the Add Directory and Edit Directory dialogs from inside the scan-job editor to maintain the directory list.

6.6.2 Notifications sub-tab

The Notifications sub-tab decides which Defender events the Console surfaces as notifications. It is organised into ten sections — eight Defender event categories plus two NetLock-side controls:

• Antivirus
• Antispyware
• Behaviour
• Configuration
• Platform
• Quarantine
• Real-time Protection
• Scan
• Signatures
• NetLock — channel selector for the events above. The five toggles (E-mail, Microsoft Teams, Telegram, NTFY.SH, Webhook) decide which deployment-wide channels carry this policy's Defender notifications. The channels themselves (server addresses, recipients, tokens) are configured globally in Settings → Notifications — see A.8 Notifications deep dive.

Each Defender category contains a list of per-event toggles — for example Antivirus enabled, Antivirus disabled, Behaviour detected, Quarantine cleared. Toggling an individual event controls whether that specific Defender event generates a notification through the Console's notification system.

Note: Silencing a noisy event category here does not disable the underlying Defender behaviour on the endpoint. It only stops the Console from forwarding the event as a notification. Defender continues to act normally and log the event locally.

6.7 Windows tab — Application Control

The Application Control sub-section of the Windows tab (on-screen heading Application Control (Whitelisting)) controls how a policy enforces application allowlisting on its devices. Ruleset content — the actual allow rules — lives in Chapter 8.6. This tab decides which ruleset to apply and how the agent reacts when an unknown process appears.

Top-level configuration:

• Enabled — master switch for this policy.
• Ruleset — single-select dropdown picking one ruleset (None is the default).
• Auto-whitelist (agent automatically adds running processes to whitelist) with Auto-whitelist until date — during this window the agent records every running process into the whitelist; after the date passes, only the collected list is enforced.

Actions on unknown process. What the agent does when a process not matched by the ruleset is detected. Toggle any combination:

• Terminate process
• Suspend process
• Delete binary
• Backup binary
• Dump process memory

Actions on parent process. The same five actions applied to the parent of the offending process — useful for chain-of-execution responses (for example, terminate a launcher that spawned the unknown child).

Matching Filters. Which attributes of a binary are compared against the ruleset. Twelve toggles:

• File: File Path, File Company, File Product, File Copyright, File Brand, File Product Version, File Version, File SHA256, File SHA512.
• Certificate: Certificate Owner, Certificate Issuer, Certificate SHA1.

Special Filters.

• Auto-allow Microsoft signed applications — bypass the ruleset for any binary signed by Microsoft.

Other Settings.

• Periodic check interval (minutes) — agent recheck cadence (5–1440).
• Tray icon notifications — show the on-device user a notification when something is blocked. When enabled, set Notification title and Notification message. The message supports the placeholders {process_name}, {process_path}, {actions}, and {count}.

Blocked launch attempts land on the Blocked Applications tab of the Application Control rulesets page in Collections, where an admin can approve them into a ruleset. To author rulesets, edit rules, or approve blocked entries, see Chapter 8.6.

6.8 Windows tab — USB Device Control

The USB Device Control sub-section of the Windows tab (on-screen heading USB Device Control (Whitelisting)) controls how this policy enforces USB allowlisting on its devices. The whitelist itself — entries shared across all policies, scoped by device / tenant / location / group / global — lives in Chapter 8.7; this tab does not own whitelist entries.

Top-level configuration:

• Enabled — master switch for this policy.
• Auto-whitelist (agent automatically adds connected USB devices to whitelist) with Auto-whitelist until date — during this window the agent records every connected device into the whitelist; after the date passes, only the collected list is enforced.

Actions on unknown device. What the agent does when a USB device that does not match an approved whitelist entry is plugged in:

• Eject / disable device
• Log device event

Device Type Filters. Which classes of USB device this policy monitors. Each class has two toggles — the class itself, and an Include Instance ID toggle that switches to strict matching (specific port / instance) rather than vendor / product matching:

Other Settings.

• Periodic check interval (minutes) — agent recheck cadence (1–1440).
• Tray icon notifications — show the on-device user a notification when a device is blocked. When enabled, set Notification title and Notification message. The message supports the placeholders {device_name}, {device_type}, {actions}, and {count}.

Blocked devices land on the Blocked Devices tab in Collections, where an admin can approve them at one of five whitelist scope levels (device, tenant, location, group, or global). See Chapter 8.7 for the scope model and approval flow.

6.9 Linux tab — UFW firewall

The Linux tab currently covers one Linux-only feature: UFW, the Uncomplicated Firewall.

The UFW section has two master toggles, a default-policy block, and two separate rule tables.

Master toggles:

• Enabled — enables UFW management by this policy.
• UFW active on device — sets UFW's own active/inactive state on devices under this policy.

Default Policies:

• Default incoming — Deny, Allow, or Reject.
• Default outgoing — Allow, Deny, or Reject.

Simple Rules. Inline table for common port-based rules:

An Add Rule button above the table creates a new row. Editing is inline — there is no separate dialog.

Advanced Rules. Inline table for rules that need source / destination specifics:

Same Add Rule and inline-editing pattern as Simple Rules.

Enforcement model. On every sync cycle the agent rebuilds UFW from the rules defined here — any existing rule not in this policy is removed. The agent also monitors UFW for external changes and re-applies the policy rules on the next check (tamper protection). Two outbound safety rules for NetLock RMM communication and remote-control endpoints are always injected automatically, so a misconfigured ruleset cannot lock the agent out.

Caution: Enabling UFW with Default incoming = Deny and no matching simple rule will block every inbound connection except the agent's own safety paths. Build the ruleset first, then flip UFW active on device on.

Note: UFW must be installed on the target device (apt install ufw). Distributions that do not ship UFW are silently skipped by the agent.

Settings here have no effect on Windows or macOS devices.

6.10 Sensors tab

The Sensors tab attaches sensors from the Sensors library to the policy. Sensor mechanics — the nine sensor categories, severity levels, notification and action thresholds, and action-script hooks — are documented in Chapter 8.3.

Within this tab you pick from sensors already defined in Collections and toggle them on for the policy. Devices assigned the policy run the selected sensors on their schedule, evaluate thresholds on the agent, and report readings back to the Console for dashboards, events, and action-script execution. Sensor-specific configuration (category, thresholds, action script) lives in the sensor definition itself, not here.

6.11 Jobs tab

The Jobs tab attaches jobs from the Jobs library to the policy. Job mechanics — the twelve schedule types, hidden jobs, and the Script reference — are documented in Chapter 8.2.

You pick jobs that should run on devices under this policy. Each job carries its own schedule from the job definition; the policy is the attachment point that decides which devices receive which jobs. Jobs flagged hidden do not appear in the Events view and are typically used to collect data that populates Custom Fields — see Chapter 8.4.

6.12 Patch Management tab

The Patch Management tab is where you configure how a policy's devices actually install approved patches. It complements the global approval queue in Chapter 7 — Chapter 7 answers "which patches may be installed at all?", this tab answers "when and how do these specific devices install the approved patches?".

The tab is laid out as five sub-tabs — Global, Windows, Linux, macOS, Docker. Global carries cross-platform defaults; the four platform sub-tabs configure their respective rollout behaviour and do not inherit from each other.

Global sub-tab

Defaults applied across all four platforms:

• Check minimum free disk space before patching — if on, skip devices below the threshold.
• Minimum free disk space (%) — numeric, 1–50.
• Catch up missed patches (install if device was offline during scheduled window) — install missed patches when the device comes back online.
• Metered connection behavior — Block patching on metered/cellular connections or Allow patching on metered/cellular connections.
• Automatic patch rollback (defer update if failure rate exceeds threshold) — pause rollout if too many devices fail a patch.
• Failure threshold (%) — numeric, 1–100.

The patch-management mode (Disabled / Informational / Managed) is not in the Global sub-tab; it is set per platform under that platform's General sub-tab.

Platform sub-tabs

The four platform sub-tabs do not share a uniform sub-tab structure:

The common Windows / Linux / macOS sub-tabs configure:

• General. Sets the patch-management mode for this platform:

  • Disabled — the agent does nothing.
  • Informational — the agent reports available patches but does not install them.
  • Managed — the agent installs patches per this policy's rules.

  Plus per-platform source toggles: Windows exposes Install OS patches (Windows Update), Install application patches (Winget), Install application patches (Chocolatey), and a Disable Windows built-in automatic updates (take control via NetLock RMM) switch (forced on in Managed mode). Linux exposes Install OS packages (apt/dnf/yum). macOS exposes its own OS-source toggles.

• Approval & Filtering.

  • Approval Gate — Only install patches that have been approved in Patch Management. When on, only Approved patches install; Pending, Rejected, and Deferred are skipped. This is the bridge to Chapter 7.
  • Allowed Severities — explicit checkboxes for Critical, High, Medium, Low, Unspecified, Informational.
  • Allowed Update Types (Windows) — Security, Regular, Definition, Rollup, Service Pack, Feature, Driver, Other. Linux and macOS expose a Preferred Update Source selector (Auto-detect / APT / DNF / YUM on Linux; equivalent on macOS) instead.

• Deployment Rings. Per-severity scheduling. For each of critical, high, medium, low, unspecified, informational, pick a Ring Type:

  • Immediate — install as soon as the patch is eligible.
  • After N days — install N days after the patch becomes eligible (N from a paired numeric field).
  • Patch Tuesday + N days — install N days after the most recent second-Tuesday Microsoft release.
  • First weekend after Patch Tuesday.
  • Second weekend after Patch Tuesday.

  Rings are per-severity within one policy, not per-device cohort.

• Schedule.

  • Allowed patch days — seven day-of-week checkboxes.
  • Maintenance window — From and To times (set them equal for a 24/7 window).
  • Smart Maintenance Window — Enable smart maintenance window (auto-detect ideal patch time). When on, optional sub-conditions: Require user idle + Idle duration (minutes) (15–480), Require AC power (for laptops), No active RDP sessions.

• Reboot. Reboot behavior after patch installation with three values:

  • Automatic reboot — reboot without prompting.
  • Ask user (with maximum deferral) — prompt the user; Maximum deferral (hours) (1–168) caps the delay.
  • Do not reboot — leave reboot to the user / next maintenance cycle.

  Plus Install all pending patches before rebooting and Notify user via Tray Icon when reboot is required. This is the only place reboot policy is configured — Chapter 7 does not surface reboot controls.

• Notifications (Windows only). End-user tray notifications during patch operations — these are not the deployment-wide notification channels in A.8 Notifications deep dive. Toggles include Notify user when updates are being installed with Installing — title / Installing — message text, Show update category to end user, Show individual update names, per-category suppression checkboxes (Security, Regular, Definition, Rollup, Feature, Driver, Service Pack, Other, Application (Winget)), Reboot required — message, and a pre-warning block (Show pre-warning notification before updates start + minutes-before-start + message template with a {time} placeholder).

• Retry. Retry count for failed patches (0–10) and Retry delay (minutes) (10–1440).

The Docker sub-tab is structured differently:

• General. Docker mode and platform-level options.
• Behavior. Docker-specific install behaviour.
• Schedule. Maintenance window equivalent.
• Registries. Registry credentials and per-registry preferences.

Note: The per-platform structure lets you run a tight maintenance window on Windows servers and a looser one on Linux workstations from the same policy. There is no implicit inheritance between platforms — Linux patching uses the Linux platform's sub-tabs regardless of what Windows is configured to do.

Every sub-tab is self-contained; you do not have to fill in all of them before a policy is usable. A minimal patch configuration is often just General (mode = Managed, source toggles) plus Schedule (a maintenance window).

6.13 App Hub tab

The App Hub tab curates which apps from the global App Hub catalogue are visible in the tray icon for devices under this policy.

For each app in the catalogue you can toggle:

• Whether the app appears in the tray window for devices under this policy.
• Whether the agent auto-updates the app when a new version is available in the catalogue.

This tab is a catalogue curation — it decides what the end user sees in the tray. It does not deploy apps. Deployment happens through Software Deployment in Chapter 8.8, which is independent of any policy.

The App Hub catalogue itself (manual app entries, catalogue browsers for Winget / Flathub / Chocolatey, Refresh catalogs sync) lives in Chapter 8.5.

6.14 Applying a policy

The short answer to "how do I apply this policy to a device, group, or tenant?" is: you don't, directly.

Policies are routed to devices exclusively through Automations. To put this policy on a device you:

1. Identify an attribute of the device that should trigger this policy — device name, tenant, location, group, internal or external IP, or domain.
2. Create an automation whose condition matches that attribute and whose target is this policy.
3. Adjust the rule's priority so it takes precedence over any other matching rules.

That is the entire procedure. There is no "Apply Policy" button on the Policies page. There is no "Attach to group" affordance on the Groups page. There is no "Set policy" action on the Devices page. See Chapter 5 for the routing layer and a worked example.

Tip: If you like to see what policy is being applied to what device, open the device overview. There is a column called policy that displays the current assigned policy.".

Permissions

Policies are gated by five permission flags:

• policies_enabled — master flag. A user without this flag does not see the Policies navigation entry and cannot reach /policies or /policy_settings.
• policies_add — create a new policy from the Manage Policies page.
• policies_manage — click Manage on a policy row to open Policy Settings for editing.
• policies_edit — save changes in the Policy Settings editor.
• policies_delete — delete a policy.

Permissions for features that live inside a policy (Antivirus, Application Control, Device Control, Patch Management, Sensors, Jobs, App Hub) are covered in their own Collections sections — see Chapter 8 — and in Chapter 14.

Related chapters

• Core Concepts — the one-policy-per-device rule in context.
• Chapter 4 — Tenants, Locations & Groups — the attributes policies are routed against.
• Chapter 5 — Automations — the only way to assign a policy to a device.
• Chapter 7 — Patch Management — the global approval queue that the per-policy rollout rules draw from.
• Chapter 8 — Collections — Scripts, Jobs, Sensors, Custom Fields, App Hub, Application Control, Device Control, Software Deployment.
• A.7 Remote screen control — deployment-wide remote-control defaults.
• A.8 Notifications deep dive — channels and recipients for Antivirus, Patch, and other notifications emitted by policy rules.

Patch Management

The Patch Management page is the Console's view of the fleet-wide patching pipeline. It answers two questions: which patches are approved to install anywhere in the estate? and what is my compliance posture against the patches that exist?. It deliberately does not answer "when does a specific policy's devices actually reboot?" — that configuration lives inside a policy.

7.1 Scope — this page versus the policy editor

Patch Management in NetLock RMM is split across two places on purpose:

• The Patch Management page at /patch-management — the subject of this chapter — is global. It shows every patch the system knows about, holds the approval state for each, tracks compliance against SLA thresholds, displays known vulnerabilities, and configures deployment-wide patch defaults. It is a queue and an observatory, not a scheduler.
• The Policy Settings → Patch Management tab — documented in Chapter 6.12 — is per-policy. It decides when and how the devices assigned to a given policy actually install the patches that have been approved on this page. That is where the per-platform rollout rules, deployment rings, maintenance windows, reboot behaviour, notifications, and retry configuration live.

Both chapters cross-link. Do not expect to find rollout scheduling or reboot controls on the page covered here.

7.2 The four tabs

Patch Management is a single page with four tabs across the top:

Actions in this chapter all happen inline — there are no standalone dialog windows on this page. Row menus and toolbar buttons take you through the workflows directly.

7.3 The approval workflow

Every patch in the Update Approval tab is in one of four states:

• Pending — newly discovered; no admin decision yet.
• Approved — eligible for installation anywhere the policy-level rules allow it.
• Rejected — explicitly blocked fleet-wide; no device will install it.
• Deferred — postponed. The default defer period is 7 days; after the timer expires the patch returns to Pending.

From the table toolbar you can act on one or many selected rows. Available actions:

• Approve — set state to Approved.
• Reject — set state to Rejected. A confirmation is shown ("Are you sure?") because rejection is a fleet-wide block.
• Defer — postpone for N days (default 7).
• Reset to Pending — revert from any other state.

Every state change triggers an immediate re-sync of every device. Devices do not wait for their next scheduled poll — the updated approval set lands on every agent as soon as the server can deliver it.

Important: Approval on this page is global. There is no per-device, per-group, per-location, or per-tenant approval on the Patch Management page. Narrowing a patch's rollout to a subset of the fleet is done with the Approval & Filtering and Deployment Rings sub-tabs inside a policy (see Chapter 6.12).

7.4 The compliance model

Each row in the Update Approval tab carries three compliance indicators in addition to its approval state:

• Installed — count of devices that already have the patch installed.
• Pending — count of devices where the patch is available but not yet installed.
• SLA Status — one of Compliant, At Risk, Overdue.

SLA status is computed per row based on the patch's severity and how long it has been known. The threshold for each severity is the number of days after first discovery within which a device is expected to have installed the patch:

SLA state transitions:

• Compliant — within SLA. The deadline has not passed.
• At Risk — three days or fewer to the deadline.
• Overdue — the deadline has passed on at least one device.

Change the thresholds on the Settings tab if your environment operates to a different cadence.

7.5 The Vulnerabilities tab (cooming soon)

The Vulnerabilities tab shows known CVEs that affect devices in your fleet. Data comes from two sources:

• The National Vulnerability Database (NVD) — the authoritative public feed of CVE records.
• The Console's own device inventory, which pairs each device's installed software with the CVE records that reference those products.

The tab is a cross-reference of the two: rows represent CVEs affecting devices you manage, with counts of how many devices are exposed and links through to those devices.

NVD data is refreshed on an interval controlled by the nvd_auto_download_enabled flag on the Settings tab. When the toggle is on, the server downloads NVD feeds automatically; when it is off, the existing data is still available but is not refreshed until you turn the toggle back on.

7.6 The Settings tab

The Settings tab holds the page's configuration knobs. These are deployment-wide — they affect the whole Patch Management page, not a particular policy.

Changes to SLA thresholds apply immediately; the next render of the Update Approval tab uses the new values to compute SLA status.

7.7 Platforms and sources

The Update Approval tab filters by platform and by source. The platform dropdown supports:

• Windows
• Linux
• MacOS
• Docker

The source dropdown supports:

Approval is per patch regardless of source. An Approved patch from Winget installs under the same rules as an Approved patch from OS-Mandatory — the per-policy Approval & Filtering sub-tab is where you gate which sources a particular policy's devices accept.

7.8 What is not on this page

Several controls that admins from other RMMs look for on a "patch management" page live elsewhere in NetLock RMM. Knowing where to find them saves time.

• Per-device or per-group exclusion lists. Not here. A patch is Rejected fleet-wide or not at all. If you need to exclude a subset, use the Approval & Filtering sub-tab inside the relevant policy (Chapter 6.12) — or split those devices into a different policy with stricter filters.
• Rollout scheduling — maintenance windows, allowed days, time ranges. Not here. Configure them on the Schedule sub-tab inside a policy's Patch Management tab.
• Deployment rings. Not here. Configure them on the Deployment Rings sub-tab inside a policy's Patch Management tab.
• Reboot behaviour and user prompts. Not here. Configure them on the Reboot sub-tab inside a policy's Patch Management tab.
• Retry on failure. Not here. Configure it on the Retry sub-tab inside a policy's Patch Management tab.
• Notifications. Not configured here. Per-event patch notifications are toggled on the Notifications sub-tab inside a policy's Patch Management tab; the channels and recipients those notifications are sent through live in A.8 Notifications deep dive.

The split is deliberate: one global decision ("may this patch install anywhere?") and many per-policy decisions ("how do these particular devices install the things that are allowed?").

Permissions

Patch Management is gated by a single permission flag in the current release:

• patch_management_enabled — master flag. Users without this flag do not see the Patch Management navigation entry and cannot reach /patch-management.

There is no finer-grained approve / reject / defer / view-only permission. A user who has the flag can perform every action on the page.

Related chapters

• Chapter 6 — Policies — the per-policy Patch Management tab, where rollout rules live.
• Chapter 6.12 — direct link to the per-policy Patch Management sub-tab reference.
• Chapter 12 — Events & Audit — event records for patch installs and approval changes.
• A.8 Notifications deep dive — channels and recipients for patch notifications.
• A.2 Updates & maintenance — Console and server update cadence, distinct from endpoint patching.

Collections

Collections is the umbrella menu group for eight reusable libraries that feed the rest of the product. Scripts, Jobs, Sensors, and Custom Fields are the programmable building blocks — small units you assemble into larger behaviours. App Hub, Application Control, and Device Control are catalogues — curated lists of packages, application rules, and USB devices. Software Deployment is an execution engine that stitches App Hub entries into ad-hoc rollouts.

8.0 How Collections relates to Policies

Five of the eight Collections sub-sections are also referenced from inside Policy Settings. That pairing is consistent: this chapter documents the library — how you author and manage the building blocks — while Chapter 6 documents attachment — how a policy picks from the library and which devices end up running or enforcing the result.

Scripts, Custom Fields, and Software Deployment have no policy-tab counterpart — they are either called from inside another Collections feature (Scripts by Jobs and Sensors) or stand alone (Custom Fields, Software Deployment).

8.1 Scripts

Manage Scripts at /manage_scripts is the library of code snippets that Jobs, Sensors, and Custom Fields draw on.

The list columns: Name, Description, Platform, Shell, Author, Date.

Create and edit a script

Two dialogs handle the lifecycle — Add Script for a new script and Edit Script for an existing one. Both share the same field set:

• Name — required.
• Description — free text.
• Default timeout — the script's default wall-clock timeout, in minutes (1 to 9999). The agent terminates the script if the timeout expires.
• Platform — one of Windows, Linux, MacOS, or System.
• Shell — gated on Platform.

Platform and Shell pair up exactly as follows; other combinations are not supported:

The System platform runs server-side database operations — typically used by SQL-backed Custom Fields and certain reporting workflows — not endpoint scripts.

The editor

The body of each dialog is a Monaco code editor with language-specific syntax highlighting driven by the selected shell. Two helpers sit next to the editor:

• Templates dropdown — starter examples for the current shell. Picking a template replaces the editor contents.
• AI Assistant — shown only when AI is enabled in Settings → AI/LLM. Opens a chat panel that can draft or refactor the script in place.

Community Scripts

The Scripts library has a community-sharing surface. Five dialogs cover it:

• Community Scripts browser — lists scripts published to the community repository. Filter by platform, shell, or keyword; preview the source; click Import to copy a script into your library.
• Import from GitHub — imports directly from a GitHub URL when the script is not in the community repository.
• Publish — pushes one of your own scripts to the community repository. Requires community permissions and the script must have a description.
• Report — reports a community script as abusive or incorrect.
• View — detailed metadata view for a community script before import.

Imports land as standard entries in your Scripts library — they are regular scripts from that moment on, editable like any other.

Tip: Set Default timeout conservatively. A runaway script that never terminates ties up an agent until it hits the limit; a five-minute default is safer than the maximum.

How Scripts are used

• Jobs pick a Script as the thing to execute on a schedule. See 8.2.
• Sensors reference a Script in two ways — as the monitoring source for the PowerShell / Python3 / Bash / Zsh categories, and as the action script to run when thresholds are breached. See 8.3.
• Custom Fields reference a Script indirectly, via the Job whose output the field parses. See 8.4.

Scripts are not called from Automations (Automations only assign policies — see Chapter 5) and are not used by Software Deployment (deployment jobs execute install scripts stored on the App Hub entry, not library Scripts).

Permissions (Scripts)

• collections_enabled — master Collections flag.
• collections_scripts_enabled — see the Scripts page.
• collections_scripts_add — create a script.
• collections_scripts_edit — edit an existing script.
• collections_scripts_delete — delete a script.

8.2 Jobs

Manage Jobs at /manage_jobs is the library of scheduled tasks. A Job wraps a Script with a schedule and a platform. The Script is the "what"; the Job is the "when".

List columns: Name, Description, Platform, Type, Author, Date, and a hidden-status icon column (shown only on hidden jobs, with tooltip "Hidden — not shown in Events").

Create and edit a job

The Add Job and Edit Job dialogs share these fields:

• Name, Description.
• Timeout — 1 to 9999 minutes. Independent of the underlying Script's default timeout; the Job's value wins.
• Schedule — dropdown of 12 options (see below).
• Platform — Windows, Linux, or MacOS.
• Type — PowerShell, Bash, Zsh, or Python3; the dropdown is filtered to what the selected Platform supports.
• Script — the Script to execute, populated from matching scripts in your library.
• Hidden — toggle. Hidden jobs do not appear in the Events view. The standard use case is a background collection job that feeds a Custom Field — you do not want it cluttering operational events.

The twelve schedule types

Jobs support twelve scheduling patterns. The same set is used by Sensors (see 8.3). Each is an entry in the Schedule dropdown:

1. System Boot — runs once per device on boot.
2. Date/Time — one-shot execution at a specific date and time.
3. Every X seconds — recurring interval in seconds.
4. Every X minutes — recurring interval in minutes.
5. Every X hours — recurring interval in hours.
6. Starting on Date, every X seconds — seconds-recurring interval that begins at a specified date.
7. Starting on Date, every X minutes — minutes-recurring interval that begins at a specified date.
8. Starting on Date, every X hours — hours-recurring interval that begins at a specified date.
9. On specific days at time — a single time plus Monday-through-Sunday checkboxes, so the job runs at the chosen time on each enabled weekday.
10. On specific days every X seconds — seconds-recurring on selected weekdays only.
11. On specific days every X minutes — minutes-recurring on selected weekdays only.
12. On specific days every X hours — hours-recurring on selected weekdays only.

Intervals in seconds exist for tight monitoring-style jobs; day-limited intervals are the usual choice for maintenance tasks that should only run during business hours.

Jobs vs Scripts

A Script is a reusable piece of code. A Job is a scheduling wrapper that picks a Script. You can point many Jobs at the same Script with different schedules — for example a "hourly quick disk check" and a "daily deep disk audit" both running the same underlying script with different timeouts and cadences.

Attachment

Jobs attach to policies via the Jobs tab of Policy Settings — see Chapter 6.11. A job with no policy attachment exists in the library but does not run anywhere.

Permissions (Jobs)

• collections_enabled, collections_jobs_enabled, collections_jobs_add, collections_jobs_edit, collections_jobs_delete.

8.3 Sensors

Manage Sensors at /manage_sensors is the library of monitoring sensors. A Sensor samples a metric on a schedule, evaluates thresholds, and optionally runs an action Script when the breach is severe.

List columns: Name, Description, Platform, Category, Sub-Category, Severity, Author, Date.

Severity takes one of four values: Critical, High, Moderate, Low. Severity is assigned at the sensor and is the label surfaced on notifications and on the Dashboard.

Create and edit a sensor

The Add Sensor and Edit Sensor dialogs share the core fields — Name, Description, Platform, Severity, Schedule (the same twelve options Jobs use), Category. The dialog then renders a conditional Sub-Category and Rule block based on the chosen category.

The nine categories

Sensors come in nine categories:

1. Utilization — host-level metrics. Six sub-categories:

   • Processor — CPU usage threshold.
   • RAM — memory usage threshold.
   • Drive — disk space or IO threshold.
   • Process CPU Usage (%) — CPU percentage consumed by a named process.
   • Process RAM Usage (%) — memory percentage consumed by a named process.
   • Process RAM Usage (MB) — memory bytes consumed by a named process.

   Rule configuration uses a threshold slider (5 to 100 percent, step 5) for the Processor / RAM / Drive variants, and a Process Name field plus a Notification Threshold Max value (0 to 9999) for the Process-CPU / Process-RAM variants.

2. Windows Eventlog — match entries in the Windows event log against a query. Useful for specific event IDs that represent failures you care about.

3. PowerShell — the data source is a PowerShell script. The agent runs the script on schedule; the script's numeric output is the sample value.

4. Python3 — same model, Python3 as the language.

5. Bash — same model, Bash as the language.

6. Zsh — same model, Zsh as the language.

7. Service — the state of a Windows or Linux service. Breaches when the service is not in the expected state.

8. Ping — ICMP reachability of a host. Breaches on loss.

9. SNMP — SNMP GET, Walk, or Monitor operation against a network device. The sensor stores credentials and queries per-sensor.

Thresholds and actions

Every sensor defines two threshold levels:

• Notification Threshold Max — when the sampled value exceeds this, a notification is generated.
• Action Threshold Max — when the sampled value exceeds this, the configured action Script runs in addition to the notification.

The action section exposes a Script dropdown, populated from Scripts that match the sensor's Platform and runtime. When the sensor breaches the action threshold, the agent executes the selected script on the device that reported the breach. This is the canonical pattern for "when disk hits 95%, run the cleanup script".

Sensor readings are one of the Dashboard's queryable data sources (see Chapter 2), and sensor breaches appear in Events (see Chapter 12).

Attachment

Sensors attach to policies via the Sensors tab of Policy Settings — see Chapter 6.10.

Permissions (Sensors)

• collections_enabled, collections_sensors_enabled, collections_sensors_add, collections_sensors_edit, collections_sensors_delete.

8.4 Custom Fields

Manage Custom Fields at /manage_custom_fields is the library of Custom Field definitions. Unlike a traditional RMM that exposes a handful of text inputs as "custom fields", NetLock RMM's Custom Fields compose entire tabs and sections of the device detail page, populated from multiple data sources.

List columns: Name, Description, Author, Date, Tabs (count of tabs this definition contributes).

The builder dialog

A single dialog — the Custom Field Builder — handles both Add and Edit. The builder is a multi-panel visual editor, not a simple form; it designs an entire device-detail-page fragment in one place.

The builder has the following structure.

Definition panel (top). Name and Description of the Custom Field set.

Header Action Buttons. A list of buttons injected into the device detail header next to the standard controls (Screen Control, Shell, and so on). Each button has:

• Label — what the button says.
• Type — URL Handler or SQL Execute.
• Icon — autocomplete over the icon set.

URL Handler buttons open a URL template. The template supports placeholder tokens {device_id} and {field_key}, which are substituted at click time. SQL Execute buttons run a SQL statement on the server; the statement supports the {device_id} placeholder and has a Require confirmation checkbox for destructive actions.

Tabs. The top-level containers on the device detail page that this definition contributes to. Each tab has:

• Target — New Tab, Existing Tab, or Existing Section. New Tab creates a fresh tab; the other two inject into a tab or section that already exists elsewhere in the detail page.
• Tab Name and Icon — shown for New Tab.

Sections. Inside each tab, one or more sections — each with a Section Name — appear as labelled blocks on the device page.

Fields. Inside each section, one or more fields. Every field has:

• Key — the programmatic identifier used in placeholders.
• Label — the human-readable name.
• Type — one of Text, Multiline, or Table.
• Data Source — one of Manual, Job Result, or SQL Select.

Data sources in detail:

• Manual — the field is free for users to edit on the device detail page. The value is stored per device.
• Job Result — the value is auto-populated from a Job's output. The builder asks for a Job Name; if you need to pluck part of the output, supply a Parse Regex. Jobs used to feed Custom Fields are typically flagged Hidden to keep them out of the Events view (see 8.2).
• SQL Select — the value is the result of a SQL query. Two modes:
  • Visual Query Builder — pick a table, pick columns (with aggregates COUNT, SUM, AVG, MIN, MAX, DISTINCT), add joins (INNER, LEFT, RIGHT), add WHERE filters with device_id already available as a placeholder, set ORDER BY and LIMIT.
  • Raw SQL — gated by a "God Mode" toggle. Lets you enter SQL directly, with {device_id} as the available placeholder.

Section Action Buttons. Each section can carry its own buttons, with the same shape as Header Action Buttons but scoped to the section. Useful when an action is only meaningful in the context of the data shown in that section.

Scope

Values are per-device. Every device that lands under a Custom Field definition has its own value set. The field metadata (keys, labels, types, queries) is shared; only the values are per-device.

Consumption

• The device detail page renders every tab, section, and field a Custom Field Definition declares — see Chapter 3.
• Dashboard panels can query the same underlying storage via the Panel Builder's SQL query builder, which lets you aggregate custom-field data across the fleet.
• Reports do not expose custom-field values as a selectable data source in the Report Builder. Custom fields appear in Reports only as optional key-value entries on the cover-page footer of a brand template — a cosmetic integration, not a queryable one. To include custom-field data in a report, write a raw SQL query against the underlying storage in God Mode, if your role has it.

Permissions (Custom Fields)

• collections_enabled, collections_custom_fields_enabled, collections_custom_fields_add, collections_custom_fields_edit, collections_custom_fields_delete.

8.5 App Hub

Manage Apps at /app_hub_manage_apps is the catalogue — the library of installable packages the product knows about. The App Hub is explicitly not a deployment engine. Deploying one of these apps to devices happens through Software Deployment (see 8.8); this page is where the list of available apps is maintained.

List columns: Icon, Name, Publisher, Version, Source (colour-coded chip: winget, flatpak, chocolatey, script), Target OS, and per-row Edit and Delete actions. Only one tab — "Apps" — is visible.

The three sources plus manual entries

Four catalogues feed the page:

• Winget — Windows Package Manager feeds, used for Windows apps.
• Flathub — the Flatpak catalogue, used for Linux apps.
• Chocolatey — Chocolatey feeds, used for Windows apps.
• Script — manual entries backed by install / update / uninstall / detection scripts you write.

Adding an app — manual entry

The Add_Manual_App dialog creates a catalogue entry by hand. Fields common to all sources:

• Name (required), Description, Version, Publisher, Author, License, Homepage, Target OS, and an icon upload.

Source-specific fields appear based on the source picker:

• Winget — Winget Package ID, Winget Source.
• Chocolatey — Chocolatey Package ID, Chocolatey Source.
• Flatpak — Flatpak App ID.
• Script — Install script, Update script, Uninstall script, Detection script, and a Script Shell selector.

The Edit_App dialog presents the same fields pre-populated against an existing entry.

Adding an app — catalogue browsers

For Winget, Flathub, and Chocolatey there are dedicated browser dialogs — Winget_Catalog_Browser, Flathub_Catalog_Browser, and Chocolatey_Catalog_Browser. Each is a searchable table of the remote catalogue with a metadata preview pane. Select a row, click Add to Catalog, and the app is copied into your local App Hub with its identifiers pre-filled.

Refreshing the catalogues

The page has a Refresh catalogs button that triggers an asynchronous sync of all three remote catalogues. Progress is shown in the page's status area; the button reports when the sync completes. Refreshing updates the versions and metadata of apps already in your catalogue and lets newly browsed apps pick up the latest remote data.

The available_for_deployment flag

Every app entry has an available_for_deployment flag. Apps with this flag set are selectable inside the Software Deployment wizard (see 8.8). Apps without it are visible in the catalogue and in the policy-level App Hub tab, but cannot be picked as deployment targets.

How policies use App Hub

The App Hub tab inside Policy Settings (see Chapter 6.13) decides which catalogue apps are visible to end users in the tray icon under a given policy. This is catalogue curation, not deployment. Selecting apps in the policy does not install anything — it decides what the tray exposes.

Permissions (App Hub)

• collections_app_hub_enabled — see the App Hub page.
• collections_app_hub_add — add a manual app.
• collections_app_hub_browse_winget, collections_app_hub_browse_flathub, collections_app_hub_browse_chocolatey — use the respective catalogue browsers.
• collections_app_hub_manage — edit, delete, and refresh catalogues.

8.6 Application Control

Application Control is an allowlist system for executables on Windows devices. Rulesets live at /application_control_manage_rulesets. The ruleset detail page is at /application_control_ruleset.

The page has two tabs.

Rulesets tab

List columns: Name, Description, Author, Date.

Actions:

• Add Ruleset — create a ruleset (Name, Description).
• Edit Ruleset — rename or redescribe.
• Delete Ruleset — delete.

Click a ruleset to open its detail page, which lists the rules inside it. The detail page has Back, Save, Edit, and Delete affordances at the top and Add, Edit, Delete actions on the rule list.

Rules inside a ruleset

Each rule identifies one allowed executable by any combination of file and certificate attributes. The Add Rule and Edit Rule dialogs share these fields (Name is required; everything else is optional and combines with AND semantics when present):

File attributes:

• File Path — absolute or pattern path to the executable.
• File Company, File Product, File Copyright, File Brand — Windows version-info strings.
• File Product Version, File Version — Windows version-info numeric strings.
• File SHA256, File SHA512 — cryptographic hashes of the executable.

Certificate attributes (for signed executables):

• Certificate Owner, Certificate Issuer.
• Certificate Begin, Certificate End — validity window.
• Certificate Public Key, Certificate Serial Key.
• Certificate SHA1.

A rule matches when every specified attribute matches the running executable. Any executable not matched by any rule in a ruleset attached to a device is blocked.

Tip: A SHA256 or SHA512 hash rule is the strongest form and does not need other fields. Path-only rules are the weakest — any file at that path matches, regardless of its contents.

Blocked Applications tab

When the agent blocks a launch attempt, the attempt is logged and surfaces on the Blocked Applications tab. List columns: Policy (the ruleset name), Count (instance count for this blocked entry), Date, Device, Process, Path, Company, Product.

From this tab you operate on selections with two actions:

• Approve Selected — inserts the blocked entries as allowed rules into the associated ruleset. The server deduplicates by SHA512 so repeat approvals do not clutter the ruleset.
• Delete Selected — removes the log entries without whitelisting.

Every entry carries a status: Pending approval, Approved, or Dismissed. Approving moves an entry to Approved and adds a rule; dismissing moves it to Dismissed without adding a rule.

Attachment

Application Control rulesets attach to devices via the Windows → Application Control sub-section of Policy Settings — see Chapter 6.7. A ruleset with no policy attachment exists in the library but enforces nothing.

Permissions (Application Control)

• collections_application_control_enabled — see the page.
• collections_application_control_add, collections_application_control_edit, collections_application_control_delete — ruleset-level lifecycle.
• collections_application_control_manage — manage rulesets broadly (Approve Selected and similar).
• collections_application_control_rules_add, collections_application_control_rules_edit, collections_application_control_rules_delete — rule-level edits inside a ruleset.

8.7 Device Control

USB Device Control is an allowlist system for removable peripherals. The same page is reachable from two routes — /device-control/whitelist and /device-control/blocked — each opening with a different tab selected.

Whitelist tab

List columns: Device Name, Manufacturer, Device ID (truncated with a tooltip showing the full ID), Scope chip (device, tenant, location, group, or global), Scope Target, Author, Date, Status (enable/disable toggle), and a per-row Delete action.

The Device ID encodes vendor-id, product-id, and serial number — the three pieces of information that uniquely identify a specific USB device (or a specific model, depending on how you later choose to scope the entry).

Blocked Devices tab

When the agent blocks a USB device, the event lands on the Blocked Devices tab.

List columns: Count, Date, Reporting Device, USB Device, Manufacturer, Type (device class: Mouse, Keyboard, HID, USB, DiskDrive, WPD, CDROM, Media, Network, XboxComposite), Device ID, Actions Taken, Status chip (Pending, Approved, Dismissed), and a context-menu actions column.

Approving a device (the only way to add a whitelist entry)

There is no standalone dialog for creating a whitelist entry. Entries are added exclusively by approving a pending row on the Blocked Devices tab. Click the row's menu icon and pick:

• Approve for this device — the whitelist entry applies only to the specific device that reported the block.
• Approve for tenant — applies to every device in the tenant.
• Approve for location — applies to every device in the location.
• Approve for group — applies to every device in the group.
• Approve globally — applies to every device in the deployment.
• Dismiss — records that the block was reviewed but should not be whitelisted.

Approving at any of the five scopes inserts a row into the whitelist with the corresponding scope type and scope target. Dismissing closes the event without adding a whitelist row.

Matching granularity

A whitelist entry matches a USB device by vendor-id, product-id, and serial (encoded in Device ID), plus device class. Serial-level matching identifies one specific physical device; vendor-and-product-only matching accepts an entire model family. You choose this implicitly at approval time — the pending row carries the device's actual identifiers, and the resulting whitelist entry inherits them.

Attachment

USB Device Control is enabled per policy through the Windows → USB Device Control sub-section of Policy Settings — see Chapter 6.8. Approving an entry or toggling its status forces an immediate re-sync so endpoints pick up the change.

Permissions (Device Control)

• collections_device_control_enabled — the sole permission gating the page in the current release. There are no separate add/edit/delete flags for USB Device Control.

8.8 Software Deployment

Software Deployment is the execution engine that drives App Hub packages onto devices. Three routes make up the feature:

• Manage_Deployments at /software_deployment — the list of deployment jobs.
• New_Deployment at /software_deployment/new — the four-step creation wizard.
• Deployment_Detail at /software_deployment/{id} — the detail view for a single deployment job.

Software Deployment is ad-hoc, not policy-driven. A deployment is created, run, and tracked as a discrete job; there is no tab in Policy Settings that composes deployments.

The deployment list

List columns: ID, Name, Author, Created, Mode (interactive or bulk), Status (pending, running, completed, completed_with_errors, cancelled), Progress (format succeeded/failed of target_count, with an error chip when failures exist), and Actions (View, Cancel, Retry, Rename, Clone, Delete).

The New Deployment wizard

The wizard has four steps.

Step 1 — Packages. Autocomplete-search the App Hub catalogue. Only apps flagged available_for_deployment = 1 are selectable. Each added package has an action dropdown — install, uninstall, or update. A single deployment may include multiple packages with mixed actions.

Step 2 — Targets. Choose the devices that should receive the deployment. You can add devices directly, or select groups, locations, or tenants; a dynamic-membership flag keeps a group target live as devices enter or leave the group.

Step 3 — Config. Per-deployment settings:

• Mode — interactive (real-time feedback in the Console) or bulk (background).
• Schedule start time — when execution may begin.
• Expiry — when unstarted targets are abandoned.
• retry_max — maximum retry attempts per target on failure.
• retry_backoff_min — minimum minutes between retries.
• Force reinstall — reinstall even if detection shows the package already installed.
• Abort on first failure — stop the entire deployment when any target fails.

Step 4 — Review and Submit. A summary view of the chosen packages, targets, and configuration. Confirming creates the deployment. If Schedule start time is in the past or unset, the deployment begins running immediately.

The detail page

The detail view shows four info cards across the top — Status, Progress, Author & Created, Scheduled / Expires — followed by a per-device results table. Action buttons at the top of the page: Back, Cancel (available while status is pending or running), Retry (available when any target has failed), Rename, Clone, Delete.

Each row in the per-device table is a target device; its inner data is an attempt history surfaced through the per-device results dialog.

Per-device result detail

The per-device results dialog shows every attempt the deployment made on one device. Per attempt it displays:

• Job Item ID, Attempt number.
• Outcome — success or failure chip.
• Exit code, Duration, Started and Finished timestamps.
• Error summary — an alert block if the attempt raised a specific error.
• stdout tail and stderr tail — trimmed output from the install script.

This is the primary forensic view when a deployment has failures — exit codes and stderr tails tell you whether the failure is a package problem, a permissions problem, or a transient network issue.

Retry and the Retry button

The Retry button on the detail page re-queues every failed target in the deployment. Retries respect retry_max and retry_backoff_min from the original configuration and increment the attempt counter. Successful targets are not touched. This is the standard remediation workflow — fix whatever caused the failure, then press Retry.

Ad-hoc single-device deployment

The Deploy Software dialog is a compact single-device flavour of the wizard, launched from outside the main Software Deployment page (for example from a device detail view). It carries the selected device's identity along with a package autocomplete and an action dropdown. Run Now creates the job and starts it immediately without the full wizard.

Relationship to App Hub

App Hub is the catalogue of what can be installed; Software Deployment is how it gets installed. A deployment pulls metadata from App Hub (package identifiers per source, install / detection scripts, elevation requirement) and wraps it in a job with targets, scheduling, retry rules, and per-device tracking. The two features are intentionally separate.

Permissions (Software Deployment)

• collections_software_deployment_enabled — see the Software Deployment pages.
• collections_software_deployment_view — view deployment lists and detail pages.
• collections_software_deployment_add — create a new deployment.
• collections_software_deployment_manage — cancel, retry, rename, clone, and delete deployments.

Related chapters

• Core Concepts — Collections as reusable building blocks.
• Chapter 5 — Automations — the policy routing layer; event-driven reactions live with Sensors, scheduled work with Jobs.
• Chapter 6 — Policies — attachment points for Jobs, Sensors, App Hub, Application Control, and Device Control.
• Chapter 7 — Patch Management — the approval queue for OS and package updates, separate from Software Deployment.
• Chapter 12 — Events & Audit — where script, job, sensor, and deployment outcomes surface.
• Chapter 13 — AI Chat — generating scripts for the Scripts library with AI assistance.
• Chapter 15 — Community — the community repository the Scripts library publishes to and imports from.

File Server & Monitoring

This chapter covers four independent features that share a menu group in the navigation. They are not part of Collections, and they are not tied to Policies. Each feature stands alone and is documented in its own section.

• File Server is a centralised storage hub for binaries, scripts, packages, and any other file you want agents or technicians to pull from a single known location.
• Relay Server lets you reach a device's TCP service (Remote Desktop, SSH, a web admin UI, a database port) through a relay tunnel when a direct connection to the device is not possible.
• Website Uptime Monitoring checks external URLs from the server on a schedule and raises events when availability, performance, SSL certificates, content, or DNS falls outside thresholds.
• Port Scanner sweeps a manually-curated list of targets for open TCP ports and surfaces findings against an allowlist.

9.1 File Server

Manage Files at /manage_files is the product's file distribution hub. Use it to publish anything your agents, scripts, or technicians need to download from a predictable place — installers, configuration bundles, intermediate artefacts a script produces on one device and another consumes, or simple documentation you want a tray-icon-initiated URL to resolve to.

List columns

The file list shows eight columns:

Upload, download, and delete

Uploads go through the Upload File action in the page toolbar. The action opens the native file picker, then streams the selected file to the File Server with a progress indicator. A single upload can carry up to 10 GB. Larger artefacts must be split before upload.

Downloads are initiated from a file's context menu. The resulting URL embeds the file's GUID, and, for private files, its Password. Public files do not require a password in the URL.

Delete is also on the context menu. Deleting a folder removes its contents; there is no separate recursive-delete confirmation beyond the standard delete prompt.

Public versus private access

Every file has one of two access levels, toggled inline in the Access column:

• Public — any holder of the download URL can retrieve the file. No password in the URL.
• Private — the download URL must include the file's Password. Without it, the server rejects the request.

Access is file-by-file. There is no directory-level ACL and no per-user ACL — any user who can reach the page can change a file's access level.

The /netlock folder

A folder named /netlock at the root is gated by a dedicated permission, file_server_netlock. Users without that permission see an empty view when they open it and cannot upload into it. Treat /netlock as the place for files you want kept out of the hands of technicians who otherwise have File Server access.

SHA512 integrity

Every file shows its SHA512 hash in the list. When a script or an agent downloads the file, you can compare that value to the hash of the received bytes to confirm the content arrived intact and was not modified in transit. The hash is computed by the server on upload and does not change unless the file is replaced.

Typical uses

The File Server is built for two audiences.

• Agents and scripts. A PowerShell or Bash script on a device fetches a file by its download URL, checks the returned hash against the published SHA512, then acts on the content. This is the standard way to distribute a large binary that would be awkward to embed in a script.
• Technicians. A private URL with a password lets you hand a customer one link to an installer or log bundle without giving them access to the rest of the File Server.

Dialogs

• Create Directory — enter a folder name to create a subdirectory in the currently open path.
• Rename — rename the selected file or folder.

There is no dedicated "Add File" dialog; the native file picker handles uploads.

Permissions

9.2 Relay Server

The Relay Server at /relay_server is the console-side view of persistent and temporary relay tunnels. A relay session proxies a single TCP port from a target device out to a connection endpoint your workstation can reach, so you can open a Remote Desktop, SSH, web admin, or database session against a device that is not directly reachable on your network.

How a relay session works

A session has three parties. The device runs the Relay App, which registers with the Remote Server and stands ready to proxy traffic. The Remote Server holds the session definition and accepts connections from your workstation on the configured relay address. Your workstation opens a TCP connection to that relay address, which the Relay App forwards to the Remote Server, which forwards it to the chosen agent, which forwards the connection to the chosen port on the device.

Everything in the tunnel is a single TCP stream. There is no UDP relaying, no multi-port session, and no protocol interpretation — the relay does not care whether the bytes are SSH, RDP, HTTP, or something else.

Persistent versus temporary sessions

Every session is either persistent or temporary:

• Persistent sessions are stored in the server's database. They survive a server restart and can be re-enabled long after they were first configured. Use persistent sessions for sites or services you expect to connect to repeatedly.
• Temporary sessions live only in server memory. They are gone as soon as the session is closed or the server is restarted. Use temporary sessions for one-off troubleshooting where the session definition is not worth keeping.

A persistent session can be toggled on or off from the list; a disabled persistent session keeps its definition but refuses new connections until you re-enable it.

Lifecycle states

A session's Status column shows one of:

• Active — a client is currently connected and bytes are flowing.
• Ready to connect — the session is registered and waiting for a client.
• Device offline — the target device's Relay App is not currently registered, so the session cannot complete.
• Disconnecting — the session is in the process of tearing down.
• Disabled — a persistent session that has been turned off via the toggle.
• Inactive — the session exists but has no registered Relay App.

List columns

The list shows:

• Device — device name, with the owning tenant name beneath.
• Target Port — the port on the device being proxied.
• Protocol — TCP.
• Status — one of the lifecycle states above.
• Connections — current count of connected clients.
• Persistent — Yes for stored sessions; blank or a Temp indicator for in-memory sessions.
• Enabled — toggle, shown on persistent sessions only.
• Actions — per-row controls.

Per-session actions

The Actions column exposes three controls:

• Copy Connection String — copies the relay address to the clipboard so you can paste it into your RDP client, SSH client, or browser.
• Enable / Disable — toggles a persistent session on or off. Not shown on temporary sessions.
• Close / Delete — closes the session and removes it from the relay server. For persistent sessions this also removes the stored definition.

How the Relay App registers

There is no discovery flow in the console. The Relay App on the device authenticates to the Remote Server using an API key and registers the sessions it is willing to serve. From that point the console can list those sessions and manage their lifecycle. Two account-area dialogs expose the API-key side of the integration:

• The Relay Identities Overview lists the API keys associated with the current admin.
• The Relay Account dialog holds the relay account settings for the current admin.

Both live in the account menu, not on the Relay Server page itself.

Create a relay session

The Create Relay Session dialog is the primary affordance for starting a new session.

Fields, in order:

• Tenant — scopes the device picker.
• Location — scopes further within the tenant.
• Group — optional; scopes further within the location.
• Device — an autocomplete picker populated by the scope above.
• Port — a dropdown pre-populated with the common services used through relays: RDP, SSH, HTTP, HTTPS, VNC, MySQL, PostgreSQL, and others. Pick a preset or type a port number directly.
• Protocol — TCP. No other protocols are currently supported.
• Description — free text for your own reference.

Submitting the dialog registers the session with the Remote Server. If the target device's Relay App is online, the session becomes Ready to connect immediately; otherwise it waits in Device offline until the Relay App registers.

Tip: For long-lived sessions you will reconnect to, enable the Persistent flag (on the list once created) rather than re-creating a temporary session each time. Persistent sessions keep their relay address across restarts.

Permissions

9.3 Website Uptime Monitoring

Website Uptime Monitoring at /website-uptime-monitoring watches external URLs from the server side. The server fires HTTP requests at each configured target on an interval, evaluates the response against a set of rules, and raises events when thresholds are breached. This is the right feature for public-facing sites, customer portals, and any HTTP endpoint where you care about availability or performance as seen from outside the device fleet.

Architecture

Checks run on the server. No agent is involved, which means a monitor sees the target from the network the server sits on — not from inside any particular customer's LAN. This matches how an external customer would reach the site, which is usually what you want for public endpoints. For internal-only URLs, consider a device-side sensor instead (see Chapter 8.3).

The three tabs

The page has three tabs, selected across the top:

• Monitors — the list of configured targets, their current status, and the affordances for add / edit / delete.
• Details — historical timeline for a selected monitor: response time, SSL certificate, DNS lookup, and content-check results over the chosen window.
• Incidents — the chronological list of raised incidents across all monitors, with start time, duration, and the reason that triggered the incident.

What a monitor checks

Each monitor performs a single HTTP request per interval and evaluates the response on multiple axes:

• HTTP status. A target has an Expected Status Code (default 200). Anything else is a failure.
• SSL certificate. If SSL monitoring is enabled, the monitor inspects the certificate chain for valid-from and valid-to dates, the issuer, subject, and thumbprint. Expiry raises a warning at the configurable warning-threshold days and critical at the critical-threshold days.
• Response time. The monitor records round-trip time and time-to-first-byte in milliseconds. A configurable threshold raises a Degraded status when exceeded.
• DNS resolution. If DNS monitoring is enabled, the monitor records lookup time and the resolved A, AAAA, and MX records.
• Content presence. With content monitoring enabled, the monitor checks the response body for a configured Keyword and for a configured CSS Selector. Either missing raises a content error.
• Defacement detection. When enabled, the monitor stores a SHA hash of the response content and alerts when the hash changes unexpectedly.

The outcome of each check is written to the monitor's history and, where thresholds are breached, produces an event under the Uptime Monitoring type (see Chapter 12.2).

List columns (Monitors tab)

• Status — one of Up, Down, Degraded, Timeout, SSL Error, DNS Error, Content Error, Pending.
• Name — the monitor's label.
• URL — the target, truncated to fit the column.
• Interval — the check cadence, formatted (for example 5m).
• Last Check — timestamp of the most recent check.
• Failures — running count of consecutive failures.
• Tenant — the tenant the monitor belongs to.
• Actions — edit / delete controls.

Creating a monitor

The monitor dialog is organised into eight sections:

• General — Tenant, Name, URL, Enabled.
• HTTP Settings — HTTP Method (GET, POST, HEAD, PUT) and Expected Status Code.
• Intervals & Timeouts — Check Interval (default 300 s, range 30 to 86400 s), Timeout (default 30 s, range 1 to 120 s), and Retry Count (default 3, range 1 to 10).
• Redirects — Follow Redirects and Max Redirects (default 5).
• SSL Monitoring — enable, warning threshold days (default 30), critical threshold days (default 7).
• Content Monitoring — enable, Keyword, CSS Selector, and the Defacement Detection hash toggle.
• DNS Monitoring — enable.
• Performance Thresholds — Response Time Alert (default 2000 ms), Load Time Alert (default 5000 ms), and SLA Target (default 99.90%).
• Notifications — per-channel checkboxes for Email, Microsoft Teams, Telegram, ntfy.sh, and Webhook. Each channel must be configured in Settings → Notifications first.

The same dialog covers add and edit; the title changes based on which action opened it.

Incidents

The Incidents tab collates the consolidated timeline of raised incidents. An incident starts when the first failing check crosses its threshold and closes when the target recovers. Each row shows the triggering reason (for example Down, SSL Error, Degraded), the monitor, the duration, and the recovery time.

Permissions

There are no granular add / edit / delete flags — access is all-or-nothing at the page level, with tenant scoping applied through the standard tenant-list permission.

9.4 Port Scanner

Port Scanner at /port-scanner sweeps a manually-configured list of targets for open TCP ports and tracks the findings against an allowlist. Use it to catch drift on internet-facing hosts — a newly opened port that shouldn't be open, a forgotten staging service exposed to the internet, or an unexpected change to a web server's Server banner.

Compliance scope — targets only

The Port Scanner scans only manually-configured custom targets. It does not enumerate the devices in your fleet and scan their external IPs. This behaviour is intentional and enforced: the Settings tab states that automatic scanning of device external IPs has been disabled for compliance reasons. If you want a host scanned, you must add it yourself as an explicit target.

The five tabs

The page has five tabs across the top:

• Scan Results — the findings table, one row per discovered open port per scan.
• Custom Targets — the targets the scanner sweeps, one host per row.
• Whitelist — the allowlist of host+port pairs that should be treated as expected rather than as a finding.
• Ports — the catalogue of port numbers the scanner will test on each target.
• Settings — global scanner configuration.

Custom Targets

Targets are added one at a time from the Custom Targets tab. Each target has a Tenant, Name, Host (hostname or IP address), and Description, plus an enabled/disabled toggle. The scanner only sweeps enabled targets.

Ports catalogue

The set of ports tested is global — not per-target. The Ports tab lets you add a port (1–65535), give it a Name (the service label shown against findings), and a Details field for notes. Each port can be enabled or disabled. A disabled port is skipped during scans but kept in the catalogue for later.

This design assumes you care about the same port numbers everywhere. If you need a different port set for a particular target, the current implementation is to maintain a single unified catalogue and filter findings by the target column of the results view.

Whitelist

The Whitelist tab is the allowlist. A whitelist entry has Tenant, Name, Host (or * for any host), Port (or 0 for any port), and Description. A finding that matches a whitelist entry is treated as expected and is not surfaced as a concern on the Scan Results tab.

Use * host plus a specific port for "this port is always OK to be open anywhere", and a specific host plus 0 for "any port being open on this host is OK".

Settings

Global scanner configuration:

• Protocols — TCP only. UDP scanning is not implemented.
• TCP timeout — milliseconds per port probe, default 3000, range 500 to 30000.
• Scan interval — hours between automatic scans, default 24, range 1 to 720.
• Max concurrent scans — maximum parallel port probes, default 50, range 1 to 500.
• Auto-cleanup — retention in days for old results, default 90.

A Trigger Scan Now button on the Settings tab runs an on-demand scan outside the interval.

Scan Results columns

• Host — the target host.
• Port — the discovered open port.
• Service — the service label from the Ports catalogue entry for that port.
• Target — the device name if the host maps to a known device; otherwise blank.
• Banner — the first bytes returned by the service, where available.
• Title (HTTP) — the <title> element of the HTTP response, if served.
• Title (HTTPS) — the <title> element of the HTTPS response, if served.
• Scan Date — the timestamp of the scan that produced this row.
• Actions — per-row controls, including opening the result details dialog.

Dialogs

• Add / Edit Custom Target — Tenant, Name, Host, Description.
• Add Whitelist Entry — Tenant, Name, Host, Port, Description.
• Add / Edit Port — Port Number, Name, Details.
• Scan Result Details — read-only display of host, port, service, banner, titles, and scan date for a single finding.

Permissions

Tenant scoping on the Custom Targets, Whitelist, and Scan Results tabs is enforced through the standard tenant-list permission.

Permissions

The File Server, Relay Server, Website Uptime Monitoring, and Port Scanner each have their own flags. The complete list for this chapter:

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 8 — Collections covers device-side sensors, which are the right choice for monitoring URLs or ports from inside a customer network.
• Chapter 12 — Events & Audit documents how Website Uptime and Port Scanner events appear in the Events view.
• Chapter 3 — Devices describes remote control, which complements the Relay Server for interactive sessions.
• Appendix X.5 — Integration endpoints lists the notification endpoints that uptime monitors and port scanner results can reach.

Tickets

Optional module: The Ticket System must be enabled in Settings → Ticket System before any of this chapter applies.

10.1 Overview

The Ticket System turns NetLock RMM into a lightweight helpdesk. Tickets capture requests and incidents raised by end users or ingested from email, carry a status through to resolution, and record every action taken along the way. The module is self-contained: it has its own contact list, its own SLA engine, and its own audit log on each ticket rather than funnelling changes into the global Events or Audit streams.

Three operator surfaces make up the day-to-day experience: the Tickets list at /tickets, Time Tracking at /tickets/time-tracking, and Statistics at /tickets/statistics. Configuration sits under the same menu group (Departments, Customers, Contacts, Templates), with dialogs for Labels & Types, SLA, and per-department Webhooks. Global defaults live on Settings → Ticket System.

10.2 Enabling the ticket system

The module is off by default. Two things have to line up for an operator to see the Tickets menu: the module must be turned on globally, and the operator must hold the tickets_enabled permission.

The master toggle is at Settings → Ticket System on the General tab, labelled Ticket System Enabled. Two other settings on the same tab apply deployment-wide:

• Ticket Number Prefix — the prefix used in generated ticket numbers. The shipped default is TKT, producing identifiers such as TKT-000123. Individual customers can override the prefix on their own record (see 10.11); the global value is used wherever no customer override exists.
• Blocked File Extensions — a chip input with one file extension per chip. Attachments with these extensions are stripped from inbound email before the ticket is created, and an internal note on the ticket names the files that were blocked. Extensions are normalised to lowercase with a leading dot, so .EXE, exe, and .exe all match.

The Settings page itself is gated by settings_system_enabled. The two extra tabs on the same page (Labels & Types and SLA) manage the same data as the dialogs reachable from inside a ticket.

10.3 The tickets list page

Route: /tickets. The queue. It opens on the Open tab by default, refreshes every 60 seconds in the background, and raises a toast whenever a new inbound email or reply arrives on a ticket the current user can see.

Columns

The list carries nine columns: Ticket #, Subject, Contact, Status, Priority, Last Contact (direction badge plus a relative time), SLA (a colour-coded urgency chip), Updated, and Assigned To. Column order is user-configurable — drag the header to rearrange — and the chosen order is persisted in the browser's local storage, so it follows the operator across sessions on the same browser but is not shared between machines.

Status tabs, filters, and search

Six tabs sit above the table: All, Open, In Progress, Waiting, Resolved, Closed. Each tab shows a live count for the current filter set; switching tabs swaps the underlying query but preserves filters, search, and column order. Closed rows are dimmed so they don't visually compete with active work on the All view.

Five filter dropdowns narrow the query:

• Department — All Departments or a named department. Users without tickets_view_all_departments see only their own department regardless of this control.
• Priority — All, Critical, High, Medium, or Low.
• Assigned To — All, Unassigned, or any operator by username.
• Type — options drawn from Labels & Types (see 10.14).
• Label — All or any colour-coded label.

Filter selections stack. A single search field sweeps Ticket #, Title, Contact Email, Contact Name, and the Assigned To username at once.

Bulk toolbar

Selecting one or more rows reveals a toolbar with Close Selected, Delete Selected, and Deselect All. Close Selected moves every chosen ticket straight to Closed without prompting for a closing comment — use the detail dialog (see 10.4) when you need to record one. Delete Selected is gated by tickets_delete and is a hard delete; there is no recycle bin.

10.4 The ticket detail view

Clicking a row opens the ticket detail dialog. Its title shows the ticket number followed by a coloured chip for the current status. The body is a six-tab editor: Conversation, Details, Time Tracking, History, Attachments, and AI.

Conversation

The Conversation tab is the primary working surface. A toggle at the top switches between Chat View — bubble layout with alternating alignment — and List View — a denser CRM-style stack. Both render the same messages in chronological order.

Every message carries a direction badge that also determines its styling:

• Internal note — left-aligned, tinted for internal use, marked with a lock icon. Not sent to the customer.
• Outbound — right-aligned, tinted blue, with an arrow-out icon. Delivered over the department's SMTP.
• Inbound — left-aligned, tinted green, with an arrow-in icon. Ingested from the department's IMAP mailbox.

A composer sits at the bottom of the tab with three editor modes: Rich Text, HTML, and Plain Text. Regardless of mode, both a rich-text rendering and a plain-text fallback are persisted, so replies display correctly for recipients that strip HTML. A lock/globe icon toggles the outgoing message between Internal note and Outbound before sending, and a Template Picker button inserts a saved response (see 10.13) — the composer remains editable after insertion.

Details

The Details tab exposes every metadata field on the ticket:

• Title.
• Status — Open, In Progress, Waiting, Resolved, or Closed.
• Priority — Low, Medium, High, or Critical.
• Assigned To Operator.
• Support Department.
• Contact Name — read-only when a contact is linked; edit the contact on the Contacts page to change it.
• Contact Email — an autocomplete-searchable input when editable. If the entered email has no matching contact, a Create Contact action appears alongside so the operator can spawn one without leaving the dialog.
• Type — a clearable dropdown.
• Labels — multi-select with the colour of each label previewed inline.
• Created / Source — captions rather than editors. Source reads Manual for tickets created from the UI and Email for tickets ingested from a department mailbox.

Edit rights split across two flags. Every field on this tab except Assigned To Operator is gated by tickets_edit; the assignee dropdown alone is gated by tickets_assign. A user who can reassign but not edit sees every other field disabled and the assignee dropdown live.

Time Tracking

The per-ticket Time Tracking tab opens with an alert reporting the state of the auto-timer: when the department has automatic time tracking enabled (see 10.10), opening this ticket starts a timer, and the timer pauses after the department's configured idle timeout.

A collapsible Add Entry form books time manually with Date, Start Time, End Time (24-hour clock), and Notes; Duration is computed read-only. Below the form, a table lists every entry on the ticket — User, Date, Start, End, Duration, Rounded (reflecting the department's rounding step), Notes, and a Delete action — and a footer summarises raw and rounded totals.

History

The History tab is the ticket's own audit log. Every status change, assignee change, field edit, and comment addition appends an entry automatically. Each row captures the author, the date and time, the field that changed, and the old and new values. This tab is the authoritative record of activity on a ticket — ticket changes do not appear in /events or /audit; see 10.17.

Attachments

The Attachments tab gathers every file attached to the ticket — whether it arrived on a comment, as an inbound email attachment, or via a direct upload — into a single table with File Name, Size, Type (MIME), Uploaded By, Date, and Actions.

Every attachment offers Download. A second action, View, appears for text-like types (.txt, .log, .json, .xml, .csv, and anything with a text/* MIME) and renders the file in an inline viewer so operators can read logs, JSON, or XML without leaving the dialog.

AI

The AI tab is present only when the AI module is enabled globally (see Chapter 13). It offers Summarize Ticket, which produces a short summary of the conversation so far, and a free-form question field for chat-style Q&A scoped to this ticket. Output renders in paper-style cards. Both features use the provider and model configured in the AI & LLM settings.

10.5 Ticket lifecycle

A ticket moves through five statuses: Open, In Progress, Waiting, Resolved, and Closed. Any-to-any transitions are allowed — there is no state machine, so an operator can move a ticket from Closed back to Open in a single step.

Three routes lead to Closed: change Status to Closed on the Details tab and save; open the dedicated Close Ticket confirmation, which prompts for an optional Closing Comment persisted as an internal note on the ticket; or select rows on the list and use Close Selected in the bulk toolbar, which does not offer a closing-comment prompt.

Closing a ticket never deletes it. Closed tickets remain visible in the Closed tab and in All, dimmed slightly so they stand apart from live work. Reopening is a plain status change — set Status back to Open or In Progress and save. The Reopened Tickets metric on the Statistics page tracks how often that happens.

Tickets can also be closed automatically by a scheduled sweep; the per-department Cleanup settings control how long a ticket must be inactive before it's caught (10.10).

10.6 Creating a ticket

The New Ticket button on the list opens the create dialog. Creation is gated by tickets_create.

One field is required: Title. Submitting an empty title raises a Title is required validation error. Every other field is optional:

• Department — falls back to the user's default department if left blank.
• Priority — defaults to Medium.
• Contact — autocomplete over existing contacts; typing searches name, email, and company.
• Contact Email — can be entered directly without selecting a contact. A contact can be created later from the detail dialog using Create Contact on the Details tab.
• Assigned To — the initial assignee.
• Type.
• Description — the opening message. If provided, it becomes the first comment on the ticket, styled as Outbound and authored by the creator.

Creating the ticket auto-fills the following:

• Ticket # — generated from the customer's prefix when the matched contact belongs to a customer that sets one, otherwise from the global Ticket Number Prefix, plus a sequential number.
• Source — Manual (Email is reserved for tickets ingested from a mailbox).
• Status — Open.
• Created Date and Created By — set from the current session.
• SLA — if the contact's email resolves to a customer with an SLA attached, the SLA's deadlines are computed and stored on the ticket.

The ticket_created webhook fires on save (see 10.16).

There is no device picker on this form. Tickets reach devices through the contact: a contact can have linked devices inside their tenant, and those devices surface on the Details tab once the ticket is saved. See Chapter 3 for the device side of that linkage.

10.7 Assignment and escalation

A ticket's Assigned To Operator is manual by default — an operator with tickets_assign picks an assignee from the dropdown. There is no queue-based round-robin or weighted distribution.

The only automated path to an assignee is Auto-assign on open, a per-department switch on the Departments admin page. When enabled, the first operator in that department to open an unassigned ticket becomes its assignee; the handoff is passive, triggered by opening the detail dialog.

SLA-driven escalation is event-based, not action-based. Tickets under an SLA carry a deadline and the list shows the current urgency as a coloured chip. When the deadline crosses a warning threshold the department's Notifications fire sla_warning, and on breach they fire sla_breached. Those events drive email notifications and webhooks (10.16). The module does not reassign tickets automatically when an SLA is at risk — a human makes that call.

10.8 Time tracking

Requires permission: tickets_view_time_tracking.

Route: /tickets/time-tracking. The page is a single-day calendar showing every time entry across every ticket the operator can see.

A vertical 24-hour timeline runs from midnight to midnight with half-hour gridlines. Entries are rendered as coloured rectangles positioned by their start and end times. The colour encodes origin: manual entries are blue, automatic entries — booked by the auto-timer — are green. On today's view, a red indicator tracks the current time.

A sidebar lists the same day's entries in chronological order with a delete button on each row. Navigation across days uses Previous, Next, a date picker, and a Today shortcut.

Each entry records Date, Start Time, End Time, Duration (computed), Rounded Duration, and Notes, plus an internal flag noting whether it was booked manually or automatically. The rounded duration applies the department's Rounding (minutes, 0 = exact) step; with 0 the rounded value equals the raw duration.

Automatic tracking is driven by three department settings:

• Idle Timeout (minutes) — after this many minutes without activity on the ticket, the timer pauses. The next interaction resumes it as a new entry.
• Confirm Timeout (minutes) — after this many minutes, the operator is prompted to confirm they're still working on the ticket. Without a confirmation the current entry stops.
• Rounding (minutes, 0 = exact) — the increment the Rounded Duration snaps to.

The page has no export control of its own; aggregate figures live on the Statistics page.

10.9 Statistics

Requires permission: tickets_view_statistics.

Route: /tickets/statistics. The page is a tabbed dashboard covering activity over a chosen time window.

A filter row at the top controls scope for every tab: a date-range picker (defaulting to the last 30 days), plus Department, Customer, and Operator dropdowns, and an Apply button that re-runs the query.

Five tabs group the metrics by category:

• Overview — volume and quality indicators across the whole scope: totals, per-status counts, average resolution and first-response times, SLA compliance, priority and source breakdowns, busiest day and hour, reopens, and so on.
• Departments — one row per department with the key volume and SLA figures.
• Customers — one row per customer with volumes, hours, and SLA compliance.
• Operators — one row per operator with workload and outcome figures, plus an operator-by-customer hours matrix.
• Trends — distributions across labels and types.

Individual metrics are not enumerated here — the tab layout and filter scope matter more for day-to-day use than the exact list, and the composition evolves with each release. The on-page labels name each metric clearly.

10.10 Departments

Requires permission: tickets_manage_departments.

Route: /tickets/departments. Departments are the organisational and technical unit of the ticket system. They carry their own mailbox, their own notification recipients, their own time-tracking behaviour, their own webhooks, and their own membership list.

The list columns are Name, Description, IMAP Server, SMTP Server, Members, Enabled, and row-level actions.

The create and edit dialogs share the same field set, grouped into sections:

• General — Name, Description, IMAP Server, IMAP Port, IMAP Username, IMAP Password, SMTP Server, SMTP Port, SMTP Username, SMTP Password, From Address, From Name, Enabled, and Auto-assign on open.
• Auto-Reply Email — Subject, Body (HTML), and an enabled toggle. Two placeholders resolve at send time: {{ticket_number}} and {{subject}}. Fires once per new ticket created from inbound email.
• Follow-Up Reminder Email — Send after X days without reply, Subject, Body (HTML), and an enabled toggle. Fires once per ticket when the customer has gone silent for the configured number of days.
• Time Tracking — Idle Timeout (minutes), Confirm Timeout (minutes), Rounding (minutes, 0 = exact), and an enabled toggle. Drives the auto-timer described in 10.8.
• Cleanup — Close tickets inactive for (days), Auto-close tickets with these statuses (checkboxes for Open, In Progress, and Waiting), Internal note added to auto-closed tickets, Delete closed tickets older than (days), and Also delete attachment files from disk.
• Notifications — Notification Recipients (comma-separated email addresses) plus an event-checkbox list: Ticket Created, Ticket Updated, Ticket Closed, Ticket Assigned, Comment Added, SLA Warning, SLA Breached, and Auto-Closed. Each selected event sends an email to every listed recipient.
• Webhooks — a Manage Webhooks button opens the webhook dialog scoped to this department. See 10.16.
• Members — a multi-select of the operators in this department. Membership combines with tickets_view_all_departments to determine who sees which tickets.

Email ingestion is per department. Each department polls its own IMAP mailbox; inbound messages create tickets in that department, and outbound replies are sent through that department's SMTP. There is no single global mailbox — to accept mail for multiple addresses, run multiple departments. Deletions are hard deletes.

10.11 Customers

Requires permission: tickets_manage_customers.

Route: /tickets/customers. Customers are the company records the ticket system operates against. A detail page lives at /tickets/customers/details for editing one customer in depth.

List columns: Company, Tenant, SLA, Prefix, and a contacts count. Creating a customer uses the Add Company dialog with these fields:

• Company Name.
• Address.
• Linked Tenant — the RMM tenant this customer maps to. The linkage scopes which devices can later be attached to the customer's contacts.
• SLA — picks an entry from the SLA library; see 10.15.
• Ticket Number Prefix — overrides the global prefix for this customer's tickets. Use something short and recognisable, such as ACME.
• Notes.

The customer detail page lets an admin edit the same fields and also surfaces the company's departments, contacts, and tickets in one place, with device links attached to each contact visible inline.

Warning: Deleting a customer is a hard delete with cascade. All departments tied to that customer, all its contacts, and the device links on those contacts are removed permanently. Remove customers only when you are sure they are gone for good.

10.12 Contacts

Requires permission: tickets_manage_customers.

Route: /tickets/contacts. Contacts are the individual people tickets are tied to. Every ticket references a contact; the contact in turn belongs to a customer, which is how the customer's SLA and prefix reach the ticket.

List columns: Last Name, First Name, Email, Phone, Position, Company, Department, and a linked-devices count. Create and edit fields are First Name, Last Name, Email, Phone, Position / Role, Company, Department, Notes, and Linked Devices. Device linking is a multi-select that only becomes available once a company is chosen — the device list is scoped to the company's linked tenant, so you can only attach devices that live in that tenant.

Contacts are also maintained inside the customer detail page. The flat /tickets/contacts page is an alternative view of the same records, convenient when you are looking for one person without knowing which customer they belong to. Deletions are hard deletes.

10.13 Templates

Requires permission: tickets_manage_templates.

Route: /tickets/templates. Templates are saved responses reusable across tickets. List columns: Name, Type (Email or Ticket), Subject, Author, Date, and an actions column.

Create and edit fields are Name, Type, Subject, and Body. The body editor offers the same three modes as the ticket composer — Rich Text, HTML, and Plain Text — and both a rich-text rendering and a plain-text fallback are persisted so the recipient sees something sensible regardless of their mail client.

The Type field reflects where the template is meant to be used: Email templates for outbound replies, Ticket templates for internal notes and descriptions on newly created tickets. Both types appear in the Template Picker; the distinction is organisational rather than enforced.

The Template Picker is available from the ticket composer and from the new-ticket dialog. Picking a template populates the subject and body of the composer and leaves both fully editable. Deletions are hard deletes.

10.14 Labels and Types

Requires permission: tickets_manage_labels_types.

Labels and Types are managed in two places: a Labels & Types dialog reachable from the ticket detail dialog and from the Settings area, and a Labels & Types tab on Settings → Ticket System. Both surfaces manage the same data.

Labels are colour-coded tags. Each label has a Label Name and a Color chosen from a hex picker. Multiple labels can be applied to the same ticket — the Details tab's label picker is multi-select. Labels are additive metadata: they don't affect routing or SLA behaviour, they just help you filter and categorise on the list.

Types are single-value categorisations. Each type has a Type Name and a Description. A ticket has at most one type.

Note: Types are user-defined. NetLock RMM does not ship a pre-configured list, and in particular does not provide the ITIL set (Incident, Service Request, Change, Problem) out of the box. Define whatever set fits your workflow.

Deletions are hard deletes with no confirmation prompt — double-check before clicking.

10.15 SLA

Requires permission: tickets_manage_sla.

SLAs are managed from an SLA Management dialog and from the SLA tab on Settings → Ticket System. Both edit the same records.

List columns: Name, Response (h), Resolution (h), Priority Override, Description, and an actions column.

Each SLA carries:

• Name.
• Response Time (hours) — the deadline for the first outbound response to the customer.
• Resolution Time (hours) — the deadline to reach a resolved status.
• Priority Override — one of None, Low, Medium, High, or Critical. Acts as a minimum priority floor: tickets under this SLA cannot drop below the override.
• Description — free text.

SLAs attach to customers on the Customers page (see 10.11). When a ticket is created from a contact of that customer, the SLA's response and resolution deadlines are computed from the creation time and stored on the ticket. The list view's SLA chip transitions through ok, warning, critical, and breached colours as the deadline approaches.

Note: SLA timers are wall-clock hours. There is no business-hours calendar — a 4-hour response time means four real hours, counted continuously including nights and weekends. Plan thresholds around that reality.

SLA timer transitions feed Notifications and Webhooks through the sla_warning and sla_breached events. Deletions are hard deletes.

10.16 Webhooks

Requires permission: tickets_manage_webhooks, granted through the department-edit context.

Webhooks are configured per department, not globally. From the department edit form, Manage Webhooks opens the webhook dialog, which lists the department's webhooks and offers create, edit, test, and delete actions.

Each webhook has the following fields:

• Name — shown in the list.
• Description — free text.
• URL — required; the endpoint the request is sent to.
• Method — one of GET, POST, PUT, DELETE, or PATCH.
• Request Body — a JSON document edited in an embedded Monaco editor, with placeholder substitution at send time.
• Request Headers — a JSON object edited in Monaco. Defaults to {"Content-Type": "application/json"}.
• Events — zero or more trigger events. Selecting none means the webhook fires for every event.
• Enabled — toggle.

The eight event triggers are ticket_created, ticket_updated, ticket_closed, ticket_assigned, comment_added, sla_warning, sla_breached, and auto_closed.

Ten placeholder tokens are substituted in the request body: {{ticket_number}}, {{subject}}, {{status}}, {{priority}}, {{assigned_to}}, {{customer}}, {{department}}, {{event}}, {{timestamp}}, and {{url}}.

The dialog pre-populates new webhooks with the following default body. Adjust it to the shape your integration expects.

{
  "event": "{{event}}",
  "ticket_number": "{{ticket_number}}",
  "subject": "{{subject}}",
  "status": "{{status}}",
  "priority": "{{priority}}",
  "assigned_to": "{{assigned_to}}",
  "customer": "{{customer}}",
  "department": "{{department}}",
  "timestamp": "{{timestamp}}",
  "url": "{{url}}"
}

A Test action sends a single request filled with sample placeholder values. Before sending, the dialog validates that the URL is well-formed and that the body and headers parse as JSON, so a misconfigured webhook fails at save time rather than at the next real event.

10.17 Notifications and Events integration

Three notification channels run in parallel for tickets:

• Email — per department. The Notification Recipients list plus the Notify on these events checkboxes decide who is emailed and for which events. Sending uses the department's SMTP configuration.
• In-app toasts — a live notification service pushes toasts to the Console on new tickets, replies, and updates.
• Unread counter — the Tickets entry in the navigation carries a badge showing unread ticket activity for the current user.

Webhook delivery is a separate fourth channel, covered in 10.16.

Note: Ticket changes do not appear in /events and do not appear in /audit. The ticket's own History tab is the authoritative activity log for every change on a ticket. If you went looking for a ticket in the global Events or Audit streams and did not find it, this is why — open the ticket itself and read the History tab.

For wider context on how each notification channel is configured (SMTP, Teams, Telegram, Ntfy, webhooks), see Appendix A.8.

10.18 Permissions

The ticket module uses a dedicated set of permission flags that gate every part of the experience. The global Settings → Ticket System page has its own flag as well, because it lives under Settings.

See Appendix X.2 for the full permission catalogue across the product.

10.19 Related chapters

• Chapter 3 — Devices covers how devices are added to tenants. Contacts in this module link to those devices, which is how tickets reach the managed estate.
• Appendix A.8 — Notifications deep dive documents each notification channel (SMTP, Teams, Telegram, Ntfy, webhooks) in detail. The department Notifications section chooses which events fire; A.8 covers how each channel is configured.
• How to handle a ticket from open to resolved is a task-focused walkthrough that puts the list, the detail dialog, time tracking, and closing into a single end-to-end example.
• Appendix X.2 — Permission reference collects every permission flag in the product, including the tickets_* set used in this chapter.

Reports

The Reports page at /reports is the console's reporting surface. It is used to build, schedule, and distribute reports about the fleet — anything from a device inventory to a patch-compliance summary to a custom SQL-backed breakdown of job outcomes. The page also hosts the community reports browser and the brand templates that give generated PDFs a consistent look.

11.1 The four tabs

The page is organised into four tabs, selected across the top:

• Templates — the library of report templates, both built-in and user-created. This is where you pick a template to generate, edit, share, publish, or duplicate.
• Generated — the list of already-produced reports, with filenames, timestamps, the template they came from, and download links for the output files.
• Schedules — the list of recurring report runs. Each row is a schedule attached to a template.
• Brands — brand templates that drive the cover page, colours, logo, and PDF footer of generated reports.

Templates drive everything. You start with a template; you generate or schedule from a template; you attach a brand to a template; you share or publish a template.

11.2 Templates

The Templates tab lists every report template you have access to. Two categories share the tab:

• Built-in templates ship with the product and are flagged with a Built-in chip. A Show Built-in checkbox in the toolbar toggles their visibility so the list can be filtered down to your own templates when the built-in set is getting in the way.
• Custom templates are created from the Templates tab's Create action, or by duplicating an existing template. They can be shared with other users via the Share Template dialog, published to the community via the Publish action, and imported from the community via the Community Reports browser.

Each template has an Author, a creation date, a description, and a list of widgets that define what the generated report contains. Templates are edited in the Report Builder (covered next).

Note: The set of templates marked built-in is defined in the product database, not hard-coded in the console. Which templates ship as Built-in depends on the database contents at installation.

Template actions

Row actions on a template include:

• Generate — open the Generate Report dialog for a one-off run (see 11.6).
• Schedule — open the Schedule dialog to attach a recurring run.
• Edit — open the template in the Report Builder.
• Duplicate — create a copy in your library, useful for editing a built-in without modifying the original.
• Delete — remove the template. Built-in templates cannot be deleted.
• Share — open the Share Template dialog to grant access to other users.
• Publish to Community — publish a template you own to the community repository.

11.3 The Report Builder

The Report Builder at /reports/builder (and /reports/builder/{id} when editing an existing template) is where a template is authored. A template is a sequence of widgets; the Builder is the editor for that sequence.

Each widget is backed by a data source — a SQL query that produces the rows the widget visualises. The Builder exposes two modes for authoring that query, gated by the user's permission level.

Visual Query Builder

The Visual Query Builder is the default mode and the one available to users who do not have admin-level report permissions. It exposes the query as a set of form controls:

• Table — the table to select from, drawn from the administrator-configured list of allowed tables.
• Columns — the columns to include in the result.
• Fn — aggregate function applied to a column. The supported aggregates are COUNT, SUM, AVG, MIN, MAX, and DISTINCT.
• Joins — a list of joins, each with a join type, a right-hand table, and an ON condition.
• Where — the filter conditions, composed with AND / OR logic. Supported operators: =, !=, <, >, <=, >=, LIKE, IN, IS NULL, IS NOT NULL.
• Logic — per-clause grouping between conditions.
• Op, Value — the operator and right-hand side for each condition.
• Order-by and limit controls round out the query.

The resulting SQL is composed by the Builder and stored on the widget.

God Mode SQL

A second mode, SQL Query (God Mode), is available when a deployment-wide setting enables it (reports_godmode in Settings). In God Mode the Widget Editor discards the visual controls and accepts raw SQL typed directly into the editor. The query runs against the full database schema — so this is the escape hatch when the visual builder cannot express what you need.

God Mode is a platform-level toggle, not a per-user permission. When the deployment has it off, no user — admin or otherwise — sees the God Mode field. When it is on, every user who can edit a report template can use it. Treat it as a deployment decision, made in Settings → Reports.

A companion AI SQL Assistant button drafts a query from a natural-language description. The AI only writes into the editor; you still review and run the query yourself.

Both modes store their output in the same widget field, so a template can mix widgets authored in either mode.

Tip: Start in the Visual Query Builder. Drop into God Mode only when you hit a real limitation — cross-schema joins, window functions, custom field values — because a Visual Query Builder query is easier to read, review, and hand off.

11.4 Widgets

A report is a sequence of widgets. Each widget is one of four types:

• Metric — a single number with a label. Use for headline figures: total devices, open incidents, unpatched criticals.
• Chart — a plotted series. Bar, line, and pie presentations are available depending on the widget configuration.
• Table — a tabular display of the rows the data source returns. The workhorse widget for inventory-style reports.
• Text — static markdown content, rendered in place. Use for narrative explanations, section headers within a report, or preamble paragraphs.

The Widget Editor

Each widget is authored and edited in the Widget Editor dialog. The dialog is divided between the widget's data source (handled via either the Visual Query Builder or God Mode SQL, as described in 11.3) and its presentation — the specific controls for the chosen widget type (axes, colours, column order, label text). The data source controls are shared across all widget types except Text, which is purely markdown and has no query.

11.5 Brand templates

Brand templates at the Brands tab let you define how a generated report looks — distinct from what it contains. A brand wraps the content of any template with a cover page and footer consistent with a specific customer, MSP unit, or product line.

The Brand Template dialog accepts:

• Company info — company name, address, contact details.
• Colours — primary and secondary colours used on the cover page and in section headers.
• Logo — the image shown on the cover page and (scaled) in the footer.
• Header text — the text line at the top of each generated page.
• Footer text — the text line at the bottom of each page.
• Custom fields — a list of key-value pairs rendered as cosmetic footer entries on the PDF cover page.
• Show custom fields in footer — a switch that controls whether those custom fields are actually rendered.

Custom Fields in reports — what they are and are not

Important: Custom Fields are not a queryable data source in the Report Builder. You cannot pick a Custom Field from a dropdown in the Visual Query Builder. Custom Fields appear in Reports in one place only: as cosmetic key-value pairs on brand template footers.

If you need Custom Field data in the body of a report — for example, a table of devices and their Asset Tag custom field — you must query the underlying tables directly in God Mode SQL. There is no visual-builder path to custom field values.

A brand template is attached to a report template via the Report Builder. One brand can back many templates; a template with no brand uses the default styling.

11.6 Scheduled delivery

The Schedules tab lists scheduled runs; each row attaches a template to a cadence and a distribution method. Schedules are created from the Schedule dialog.

Frequency

The frequency selector offers:

• Hourly
• Daily
• Weekly — with a day-of-week picker (Sunday through Saturday).
• Monthly — with a day-of-month picker (1 through 28).
• Quarterly — with a day-of-month picker.
• Annually — with a day-of-month picker.

Day-of-month is capped at 28 so scheduled runs always fire; there is no "last day of month" option.

Time

Time is expressed as Hour (0–23) and Minute (0–59), evaluated in the server's configured time zone.

Date range

The Date range selector controls the window of data the generated report covers:

• auto — driven by the report template's own configuration.
• last_24h
• last_7d
• last_30d
• last_quarter
• last_year

Output format

The Export format control selects how the generated report is rendered:

• PDF — paginated with the brand template applied.
• HTML — single-file HTML, handy for embedding in a customer portal or emailing inline.
• CSV — raw row data; suitable for further processing.
• JSON — structured form; suitable for downstream automation.

Distribution

Scheduled runs deliver through one of two channels:

• Email — the schedule carries a Recipients field (comma-separated addresses), a Subject, and a Body. The rendered report is attached to the message.
• Webhook — the schedule carries a URL, an HTTP Method (GET, POST, PUT, DELETE, PATCH), Request Headers as JSON, Request Body as JSON, and an Attach File toggle. When Attach File is on, the rendered report is sent as a multipart attachment; when off, only the request body is sent.

The distribution choice is per-schedule, not per-template — the same template can back one email-delivered schedule and one webhook-delivered schedule.

11.7 Output formats

Whether triggered from the Generate Report dialog or from a schedule, the output format is selected at run time:

PDF honours the brand template attached to the source template; the other formats ignore it.

11.8 Generating a report on demand

The Generate action on any template opens the Generate Report dialog — a one-off run.

Fields:

• Template — pre-filled from the row you clicked.
• Format — PDF, HTML, CSV, or JSON.
• Date range — the same options as scheduled delivery.
• Email — optional; if filled, the generated file is emailed to that address. Leave blank to only produce the file (it lands on the Generated tab).

11.9 Community Reports

Report templates have a community sharing surface analogous to the one on Scripts. Four affordances drive it:

• Import — the Community Reports button opens the Community Reports browser. Filter, preview, and click to import a community template into your own library as a custom template.
• Publish — the Publish to Community button on the Report Builder (visible when the template is yours) opens the Publish dialog. You provide a name, description, and metadata; the template JSON is posted to the Members Portal.
• Report — flag a community template as abusive or incorrect.
• View — open the detailed metadata view for a community template before deciding to import.

Imported templates are normal custom templates from that moment on — editable, schedulable, and deletable.

11.10 Dialogs

The Reports page and its Builder share a set of dialogs:

Permissions

God Mode SQL is controlled separately by the deployment-wide reports_godmode toggle in Settings → Reports, not by a per-user permission.

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 8.4 — Custom Fields covers where Custom Fields live in the product and how to read their values via SQL when you need them inside a report body.
• Chapter 12 — Events & Audit is the source for generating event-oriented reports.
• Part III — How-To Guides includes a step-by-step for running a compliance report and scheduling email delivery.
• Appendix A.12 — Content defaults covers the system-wide report defaults configured in Settings.

Events & Audit

NetLock RMM keeps two separate logs, each answering a different question.

• Events answers "what happened on the devices?" — antivirus detections, job outcomes, sensor breaches, uptime-monitor failures, port-scan findings, device online/offline transitions.
• Audit answers "what happened in the console?" — who logged in, who changed a policy, who approved a patch, who deleted a user.

This split is deliberate. Events is operational; Audit is administrative. Events is filterable by severity and device; Audit is filterable by user and entity type. Events can be marked read or exported; Audit is append-only and cannot be pruned from the UI. Keep the two pages separate in your head and you will always be on the right one.

12.1 Scope split

Events and Audit are not duplicates of each other. The following split is the single source of truth:

Script execution is the classic case of a record landing in both logs. The Audit entry records that a console user initiated the run (action = execute, entity_type = script). The Events entry is emitted by the device after the script finishes (type = job), with the outcome and any output. Read one without the other and you are missing half the picture.

Application Control and Device Control blocks are surfaced in Events and on their own Blocked tabs — see 12.5.

12.2 Events

Manage Events at /events is the operational log.

List columns

The list shows:

Filter controls

A filter bar across the top of the page narrows the view:

• Time span — start and end date. Defaults to the last 7 days.
• Severity — Any, critical, high, moderate, or low.
• Type — Any, antivirus, job, sensor, Uptime Monitoring, or Port Scanner.
• Tenant — dynamically populated from the tenants you have access to.
• Location — dynamically populated from the selected tenant.
• Show read events — checkbox, off by default. When off, events you have already opened are hidden.
• Show website uptime events — checkbox, on by default.
• Show port scanner events — checkbox, on by default.

The six event types

Events are categorised by type. The Type filter exposes five of them; a sixth exists but is not included in the dropdown:

The Show website uptime events and Show port scanner events checkboxes are independent of the Type dropdown. If you pick Uptime Monitoring from the Type dropdown, the events are shown regardless of the checkbox state — the dropdown wins when it names a type explicitly.

Hidden jobs are excluded

Jobs marked Hidden in their library entry (see Chapter 8.2) are excluded from the Events view at query time. There is no checkbox that brings them back — they are not visible on this page at all, regardless of filter state. Use hidden jobs for background work that feeds Custom Fields or other non-operational data flows; use non-hidden jobs when you want the outcome surfaced here.

Event Details dialog

Clicking a row opens the Event Details dialog and marks the event as read.

The dialog has two tabs:

• Monaco — the event content rendered in a Monaco code editor with syntax highlighting. Best for output that is JSON, XML, or otherwise structured.
• RAW — the plain-text form of the same content. Use this when Monaco's highlighter guesses wrong or when you want to copy content verbatim.

When AI is enabled in Settings → AI/LLM, a third control appears: the Analyze with AI button. Clicking it hands the event content to the AI chat with the event context pre-filled, so you can ask the model to explain the event without copying and pasting it by hand.

Toolbar actions

The Events toolbar exposes:

• Refresh — re-queries the server for the current filter.
• Mark all as read — marks every event currently visible as read.
• Export — exports the currently-filtered list as JSON or HTML.

There is no acknowledge affordance beyond mark-as-read and no delete affordance. Events remain on the server until retention rules (configured in Settings) remove them.

Permissions

Tenant scoping is applied through the standard tenant-list permission, so a user with access to tenants A and B will see events from devices in those tenants only.

12.3 Audit

Audit at /audit is the administrative log.

List columns

The list shows:

Filter controls

• Time span — default last 7 days.
• Severity — Any, Info, Warning, or Critical.
• Action — Any plus the ten action categories.
• Entity Type — Any plus the 18 entity types.
• User — drawn from the accounts that have ever produced an audit entry.

Action categories

Every audit entry has one of these ten actions:

Entity types

Every audit entry has one of these 18 entity types:

Immutability

There is no delete affordance on the Audit page. You cannot remove individual entries, bulk-delete, or clear the log from the UI. The log is treated as append-only.

Viewing the Audit log is itself audited. When you open the page, an entry is written with action = view and entity_type = audit_log, recording which user accessed the log and from what IP. This means the auditors can be audited — you can see who has been reading the log.

Retention

Retention is not configurable on the Audit page. The date-range picker filters what you see; it does not delete anything. Retention is a global setting under Settings → Logging (see Appendix A.9).

Audit Details dialog

Clicking a row opens the Audit Details dialog. It shows the full record: date, severity, user, source IP, action, entity type, entity ID, entity name, tenant scope, and the formatted details payload. If the details field contains valid JSON, it is pretty-printed; otherwise it is rendered as plain text. The dialog has a single Close button.

Permissions

12.4 Cross-reference: which Phase-2 feature lands where

A single console action often produces records in both logs. The table below maps common operations to the records they write — use it when you are tracking a change across systems.

12.5 Application Control and Device Control blocks

When the agent blocks an unknown application or USB device, the block is surfaced in two places at once.

On the Events page. Each block is logged as an event. It shares the antivirus type with Microsoft Defender events, so the Type filter dropdown has no separate Application Control or Device Control entry — selecting antivirus, or leaving the filter on its default, includes them. Identify them by the Reported by column, which reads Application Control [<mode>] or Device Control [<mode>].

On a dedicated Blocked tab. The same block also lands on a block-and-approve tab inside Collections:

• Application Control blocks appear on the Blocked Applications tab of Manage Application Control Rulesets — see Chapter 8.6.
• Device Control blocks appear on the Blocked Devices tab of Manage Device Control — see Chapter 8.7.

The two surfaces serve different purposes. The Events entry is the operational timeline — what happened, when, and on which device. The Blocked tab is the workflow surface — a blocked attempt is an input to the approval process, where you decide whether to whitelist it. Use Events to spot a block; use the Blocked tab to act on it.

If the policy has tray-icon notifications enabled, the on-device user additionally sees a notification at the moment of the block — configured per policy in Chapter 6.

Permissions

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 5 — Automations explains why automation-driven policy changes show up as update on policy rather than as events.
• Chapter 6 — Policies covers what a policy edit actually changes, producing the update on policy audit entries referenced in 12.4.
• Chapter 7 — Patch Management covers the approval workflow whose state changes surface as update on patch entries.
• Chapter 8 — Collections documents the Collections features whose executions appear as job, sensor, and antivirus events, and whose block logs live in their own tabs rather than in Events.
• Chapter 13 — AI Chat is where the Analyze with AI button on Event Details lands you.
• Appendix A.9 — Logging & protocols covers the retention controls that determine how long events and audit entries are kept.

AI Chat

The AI Chat page at /ai-chat is a general-purpose AI assistant embedded in the console. You open it, type a question, and get an answer — the same mental model as any chat-style assistant. It is useful for quick lookups, explaining log output, drafting wording for a customer email, or sanity-checking a configuration choice before making it.

The feature depends on two switches being on. First, ai_enabled — a system-wide flag configured under Settings → AI/LLM, which also holds the provider, API key, and model. Second, ai_chat_page_enabled — a per-user permission that gates access to this page specifically. With ai_enabled off, the page shows the message "The AI provider has not been enabled. Ask your administrator to configure it under Settings → AI / LLM." and no conversation can be started. With ai_chat_page_enabled off, the page is not in the user's navigation menu.

13.1 The chat UI

The page is a two-column layout: the conversation sidebar on the left, and the active chat on the right.

Sidebar

The sidebar lists your past conversations. At the top:

• New chat — starts a fresh conversation.
• A search field with placeholder text Search conversations... that filters the list by title.

Below, conversations are grouped by recency:

• Today
• Yesterday
• Last 7 days
• Last 30 days
• Older

Each conversation shows its title, the time of its last update, and an optional context badge when the conversation was started from another part of the console (for example, when you launched the chat from the Analyze with AI button on an event).

Chat pane

The chat pane is the right column. It shows:

• A header strip with the AI avatar, the conversation title, the optional context badge, and Rename and Delete controls.
• The message area, with date dividers between different days.
• Chat bubbles: your messages right-aligned, the AI's responses left-aligned with the AI avatar.
• Markdown rendering for AI responses — code blocks, numbered and bulleted lists, tables, links, and blockquotes render as you would expect.
• A typing indicator while a response is being generated.
• Streaming updates as each chunk of the response arrives, so the answer appears incrementally rather than all at once.

Composer

At the bottom of the chat pane:

• A file attachment control, labelled Attach text-based files (max 10 MB each).
• The message textfield, with placeholder Type your message... normally and AI is responding... while a response is streaming.
• A send button that swaps into a stop button while streaming. Pressing stop cancels the current response.

13.2 Conversations

Creating a conversation

Clicking New chat creates an empty conversation with an auto-generated title. The title is derived in this order:

1. From the first message text, trimmed to a short string.
2. From the first attachment name, if the first action is attaching a file.
3. From the literal New Conversation, if neither of the above applies.

You can rename a conversation at any time from the Rename button in the chat pane header.

Renaming a conversation

The Rename Conversation dialog accepts a new title in a single text field. Submit to save; the new title appears immediately in the sidebar list.

Deleting a conversation

The Delete Conversation dialog asks for confirmation. Deletion is permanent — the conversation and all its messages are removed. Titled Delete conversation, the dialog is a one-click confirmation.

Exporting a conversation

There is no export affordance on the AI Chat page. If you need a record of a conversation, copy the content out of the browser by hand.

13.3 Attachments

The composer accepts text-based files, prepended to the outgoing message so the AI receives both your prompt and the file contents in one pass.

Allowed types and limits

• File types — text-based only. A whitelist of 40+ extensions covers the common cases: plain text, Markdown, source files across the major languages, YAML, JSON, XML, INI, CSV, logs, and configuration formats. Binary formats are not accepted.
• File size — 10 MB maximum per file.
• Files per message — up to 10 files can be attached to a single message.

How content is included

When you send, the content of each attached file is prepended to your message with markers so the AI can tell where each file starts and ends:

--- Attached file: {name} ({size}) ---
{file contents here}
--- End of {name} ---

The full content is sent — there is no truncation within the 10 MB per-file limit. Very large prompts may run into the provider's own token limit; the response will surface an error if that happens.

Attachment View dialog

Click an attachment chip in an existing message to open the Attachment View dialog, which shows the file name, a size label, and the full content as it was sent. Use this to verify exactly what was passed to the AI.

13.4 What AI Chat is not

A few points that come up often enough to call out explicitly, so readers coming from related parts of the product don't spend time looking for things that aren't there.

It is not the Scripts editor's AI Assistant

The AI Assistant button inside the Scripts editor (see Chapter 8.1 — Scripts) is a separate integration. It lives inside the Add Script and Edit Script dialogs, has its own inline panel, and is wired to write directly into the script editor. It is not the AI Chat page opened in a side panel.

The AI Chat page does not have a "Save as Script", "Save as Job", or "Save as Sensor" button. It cannot push a conversation into the Collections library. If you want to save a script the AI drafted, copy its code from the conversation, open the Scripts library, and paste it into a new script manually.

The same applies to the AI Assistant buttons on the Automations dialogs, the Widget Editor's AI SQL Assistant, and the Analyze with AI button on event and audit details — each of these is a targeted integration at its page, not the AI Chat page.

It does not show provider or model

The chat UI does not display the configured provider name, model name, or parameters to the end user. These live in Settings → AI/LLM (see Appendix A.11) and are only visible to users with access to that Settings page.

If you need to know which model is answering you, ask the administrator, or ask the model — it will usually tell you.

It does not integrate with Collections

The AI Chat page is general-purpose. It does not know about your Scripts, Jobs, Sensors, Custom Fields, App Hub entries, Application Control rulesets, or Device Control entries. It cannot look up a device, assign a policy, or trigger a deployment. For those interactions, use the relevant console page directly.

It does not export conversations

Already noted above — no export, no download, no shareable link. Treat conversations as transient.

13.5 Dialogs

Permissions

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 8.1 — Scripts covers the Scripts editor's AI Assistant — the integration that does write into a Script.
• Chapter 12.2 — Events covers the Analyze with AI button on the Event Details dialog, which opens AI Chat with the event pre-filled.
• Appendix A.11 — AI / LLM configuration covers the provider, key, and model settings that back the chat.

Users & Roles

The Users page at /users is where console user accounts are created, edited, and deleted. User accounts are the identities that sign in to the console — not the agents, not the devices, not the customers. One account per technician.

NetLock RMM's access model is per-user permissions, scoped to tenants. There is no separate Roles page and no role templates to assign — control is exercised through a permission matrix on each user account. Read this chapter before spending time looking for role management elsewhere; the access model is explicit, flat, and per-user, and understanding it up front saves confusion later.

14.1 The Users list

The Users list shows one row per user account.

Toolbar actions include Add User, Manage (open the selected user's settings), and Export Data to JSON or HTML.

Double-clicking a row, or using the Manage action, opens the user's settings page — covered in 14.3.

14.2 Creating a user

Add User opens the Add User dialog.

Fields:

• Name — required. This is the username the user will log in with.
• Password — auto-generated, 12 characters, read-only in the dialog. The dialog also exposes a Copy to Clipboard button that copies both the username and password in one action, so you can paste them into your password manager or the credential-delivery workflow of your choice.
• Role — a dropdown. In the current release this dropdown contains only Administrator; the value is stored as a free-text label on the user row and does not by itself grant or deny any permissions (see 14.4).
• Auth Mode — Password, SSO, or Password & SSO. Chooses how the user signs in.
  • Password — local password only.
  • SSO — single sign-on only; local password is unused.
  • Password & SSO — either mechanism works.