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.