Auto-Apply Rules

Auto-apply rules allow NetXMS to automatically apply templates to nodes based on node properties. Instead of manually assigning templates to each node, you define a filter script and NetXMS evaluates it periodically for candidate objects.

How Auto-Apply Works

  1. You configure a filter script on a template

  2. The filter is evaluated during the template’s Automatic binding poll and during each candidate object’s configuration poll

  3. If the filter returns true, the template is automatically applied to the object

  4. If the filter returns false and auto-remove is enabled, the template is removed from the object

  5. If the filter returns null, nothing is changed

This ensures that nodes always have the correct templates applied based on their current properties.

Configuring Auto-Apply

  1. Open the template properties

  2. Go to the Automatic Apply Rules page

  3. Check Apply this template automatically to objects selected by filter

  4. Enter the filter script in NXSL

Auto-Apply Options

Option Description

Apply this template automatically to objects selected by filter

When checked, the template is automatically applied to objects matching the filter

Remove this template automatically when object no longer passes through filter

When checked, the template is automatically removed from objects that no longer match the filter

Exclusion group

Only one template from an exclusion group can be applied to an object at a time

Filtering script

NXSL script that returns true, false, or null

If only automatic apply is enabled (without automatic remove), templates are only applied to matching nodes but never automatically removed. This is the safer option when you want to ensure templates are not accidentally removed if a node’s properties change temporarily.

Automatic removal can be delayed with the DataCollection.TemplateRemovalGracePeriod server configuration variable (days, default 0 = immediate). With a grace period set, removal is scheduled and cancelled automatically if the object matches the filter again before the period expires.

Filter Scripts

The filter script is written in NXSL. The object being tested is available as $object; when it is a node, it is also available as $node. The template itself is accessible as $template (and also as $container). The script must return true (apply the template), false (do not apply, or remove if auto-remove is enabled), or null (make no changes).

Common Filter Examples

Apply to all Linux nodes:

return $node.platformName ilike "linux*";
like is case-sensitive; the agent reports platform names such as Linux-x86_64, so use ilike or match the exact case.

Apply to nodes in a specific zone:

// $node.zone is null when zoning is disabled
return $node.zone != null && $node.zone.uin == 10;

Apply to nodes with a specific custom attribute:

return $node.customAttributes["role"] == "webserver";

Apply to SNMP-capable nodes from a specific vendor:

return $node.isSNMP && $node.sysDescription like "*Cisco*";

Apply to nodes with a name matching a pattern:

return $node.name ~= "^db-prod-\d+$";

Apply to nodes running a specific Linux distribution:

return $node.sysDescription like "*Ubuntu*";

For agent nodes, sysDescription contains the System.Uname output (e.g. Linux host1 6.8.0-31-generic #31-Ubuntu SMP …​ x86_64); the distribution name appears in the kernel version banner, but the OS release number does not, so a pattern like Ubuntu 24 would never match.

Combining Conditions

You can combine multiple conditions:

// Apply to Linux servers in the production zone that have the agent
return $node.platformName ilike "linux*"
    && $node.zone.uin == 1
    && $node.isAgent;

Using Asset Attributes

If you use asset management, you can filter based on asset properties:

props = $node.assetProperties;
return (props != null) ? props.department == "Engineering" : false;

Evaluation Timing

Auto-apply rules are evaluated during the Automatic binding poll, which runs at the interval defined by the Objects.AutobindPollingInterval server configuration variable.

By default, auto-apply filters are also evaluated during the Configuration poll. This behavior can be disabled by setting the Objects.AutobindOnConfigurationPoll server configuration variable to false.

Object Classes Considered

By default, the Automatic binding poll evaluates template auto-apply rules only for nodes. Other object classes are considered only if the corresponding server configuration variable is enabled (all are disabled by default):

Object class Server configuration variable

Access points

Objects.AccessPoints.TemplateAutoApply

Clusters

Objects.Clusters.TemplateAutoApply

Collectors

Objects.Collectors.TemplateAutoApply

Mobile devices

Objects.MobileDevices.TemplateAutoApply

Sensors

Objects.Sensors.TemplateAutoApply

The configuration poll path evaluates auto-apply rules only for nodes, sensors, clusters, and access points. Templates are auto-applied to collectors and mobile devices only by the Automatic binding poll, and only when the corresponding variable is enabled.

Auto-Apply vs Manual Apply

Aspect Auto-Apply Manual Apply

Effort

Automatic, no per-node work

Requires action for each node

Consistency

All matching nodes are guaranteed to have the template

Easy to miss nodes

Reactivity

Responds to property changes

Static until manually changed

Control

Rule-based, less granular

Full per-node control

Removal

Optional auto-remove

Manual only

You can combine both approaches: use auto-apply for broad-category templates (platform, role) and manual apply for specialized templates.

Troubleshooting

Template Not Applied

If a template is not being auto-applied to a node you expect it to match:

  1. Verify the auto-apply filter is enabled on the template

  2. If the target is not a node (cluster, sensor, access point, collector, mobile device), check that the corresponding Objects.<Class>.TemplateAutoApply server configuration variable is enabled (see Object Classes Considered above)

  3. Test the filter script in the NXSL console with the target node

  4. Check if the node’s properties actually match the filter conditions

  5. Check for an exclusion group conflict with an already-applied template

  6. Run a configuration poll on the node, or Poll > Automatic binding on the template, to trigger re-evaluation

  7. Check the event log: SYS_TEMPLATE_AUTOAPPLY and SYS_TEMPLATE_AUTOREMOVE events are generated on every automatic apply and removal with node and template names as parameters

  8. Check the server log for auto-apply errors

Template Unexpectedly Removed

If templates are being removed from nodes:

  1. Check if "automatic remove" is enabled

  2. Verify the filter still matches the node’s current properties

  3. Check if a recent property change caused the filter to return false

  4. Consider disabling automatic remove if property changes are transient

Best Practices

  • Start with simple filters and refine as needed

  • Use $node.platformName for OS-based rules — it is populated by the agent during configuration polls

  • Prefer custom attributes or asset attributes for role-based classification over name patterns

  • Always test filter scripts in the NXSL console before enabling auto-apply

  • Use automatic remove cautiously — disable it if node properties are volatile

  • Document the filter logic in the template description