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.