Build and apply a policy

Applying configuration to a device in NetLock RMM is a two-stage task. First you build a policy that describes what should be enforced. Then you create an automation — a condition → policy rule — that routes the policy to the devices that should receive it. Policies are never attached to groups, locations, or devices directly; there is no "Apply Policy" button anywhere in the Console. The two stages are always distinct, and this guide walks through both.

At the end you will have one device running one policy, with evidence of the assignment in the device detail view and in Events.

Before you start

• At least one tenant, location, and group exists (see Guide H.3).
• At least one authorised device is online in a group you intend to target (see Guide H.1 and Guide H.2).
• Required permissions: policies_enabled, policies_add (or equivalent), automation_enabled, and automation_add.

Note: A device receives at most one policy at a time. Policies do not layer, merge, or inherit. If two automations match the same device, the higher-priority rule wins.

Stage 1 — Build the policy

1. Open Policies from the navigation.
2. On Manage Policies, click Add. In the Add Policy dialog enter a Name (for example Starter Workstations) and an optional Description. Save.
3. Click Manage on the new row to open the Policy Settings editor.
4. Step through the tabs you care about and tune settings. For a first pass the defaults on the Agent tab are usually fine — they set the sync interval and remote-control capabilities. See the full tab reference in Chapter 6 for everything you can configure.
5. Save.

Warning: Policies have no templates, no versioning, and no rollback. Edits apply in place. Before making risky changes to an in-use policy, duplicate it first from the Manage Policies page and edit the copy.

Stage 2 — Route the policy with an automation

1. Open Automations from the navigation.
2. Click Add. In the Add Automation dialog fill in:
   • Name and Description.
   • Condition — pick Group for the simplest case.
   • Expected result — enter the exact group name this policy should apply to (for example Workstations).
   • Target policy — pick the policy you created in stage 1.
3. Save.

The server immediately re-evaluates every connected device against the updated automation list and pushes matching policies. You do not need to wait for the next scheduled poll.

Tip: Automations are evaluated in priority order and the first match wins. If you have multiple rules that could match the same device, reorder them on the Manage Automations page so specific rules sit above general ones.

Verify it worked

• Open Devices and select a device in the target group. Its detail view shows Assigned policy: <your policy name>.
• Open Events and filter by the device. Look for entries that mark the policy deployment and any follow-on actions triggered by the policy.
• Optionally open Audit for an immutable record of when and by whom the policy was created and the automation added.

Troubleshooting

• Device shows no_assigned_policy_found. No automation matched the device. Re-check the automation's condition and expected value — an exact string match against the device's group is required.
• Wrong policy is assigned. Another automation higher in the priority order matched first. Reorder or narrow the higher rule.
• Policy saved but no events appear. Confirm the device is online in Devices. A device that is offline picks up the policy on its next sync. For persistent offline devices, see Troubleshooting.

Related

• Chapter 5 — Automations — the policy-routing layer, the seven condition types, and priority resolution.
• Chapter 6 — Policies — complete reference for every tab in the Policy Settings editor.
• Guide H.5 — Configure Windows Defender via policy — a worked example of tuning the Windows tab.