Introduction
Conditions let you control whether an individual action actually executes during an automation run. Use them to skip an action on certain device types, target specific OS versions, check a custom field value, or branch based on what a previous action did.
How Action Conditions Work
Conditions are configured per action, not per automation. Each action in your pipeline can have its own independent condition set.
When an automation run reaches an action, Level evaluates that action’s conditions against the current device. If every condition is satisfied, the action runs. If any condition isn’t met, the action is skipped for that device.
Multiple conditions use AND logic — every condition must be satisfied for the action to run. There’s no OR option within a single action. If you need OR-style behavior, duplicate the action and apply different conditions to each copy.
ℹ️ NOTE: Action conditions are evaluated at runtime, against the specific device being processed. They’re not evaluated at trigger time — a device can pass trigger conditions and still have individual actions skipped based on action conditions.
Configuring Conditions
Conditions are set inside the action configuration panel when adding or editing an action.
ℹ️ NOTE: Actions are only editable in edit mode. From the pipeline view, click Edit in the top-right corner to enter edit mode. Clicking an action outside of edit mode opens a read-only panel showing run history.
Open the action configuration panel by clicking an existing action or adding a new one.
Expand the Conditions section.
Click the Condition dropdown and select a condition type.
Set the association (if applicable), operator, and value.
To add another condition, click + Add new condition.
To remove a condition, click Remove next to it.
Click Save to apply.
Condition Reference
ℹ️ NOTE: OS values are populated dynamically from the OS versions present in your device inventory. If your environment only has Windows devices, only Windows versions will appear. Empty dropdowns mean Level hasn’t detected any devices with that attribute yet.
Platform
Filter by the device’s operating system family.
Operator | Description |
Equal to | Device OS matches one of the selected platforms |
Not equal to | Device OS does not match any of the selected platforms |
Values: Windows, macOS, Linux. Multiple values can be selected.
Tag
Filter by tags applied to the device.
Operator | Description |
Equal to | Device has all of the selected tags |
Not equal to | Device does not have any of the selected tags |
Select one or more tags from your organization’s tag list.
Group
Filter by the device group the device belongs to.
Operator | Description |
Equal to | Device is a member of one of the selected groups |
Not equal to | Device is not a member of any of the selected groups |
Select one or more groups from your group hierarchy.
Status
Filter by whether the device is currently online or offline.
Operator | Description |
Equal to | Device status matches the selected value |
Not equal to | Device status does not match the selected value |
Values: Online, Offline.
Last seen (in days)
Filter by how many days have passed since the device last checked in with Level.
Operator | Description |
Greater than | Device was last seen more than N days ago |
Greater than or equal to | Device was last seen N or more days ago |
Less than | Device was last seen fewer than N days ago |
Less than or equal to | Device was last seen N days ago or fewer |
Enter a whole number of days as a free-text value.
Architecture
Filter by the device’s CPU architecture.
Operator | Description |
Equal to | Device architecture matches the selected value |
Not equal to | Device architecture does not match the selected value |
Values: amd64, arm64.
Hostname
Filter by the device’s hostname.
Operator | Description |
Equal to | Hostname exactly matches the entered value |
Not equal to | Hostname does not match the entered value |
Contains | Hostname includes the entered string |
Does not contain | Hostname does not include the entered string |
Enter the hostname value manually. Matching is case-insensitive.
💡 TIP: Use Contains to target naming conventions — for example, filtering to devices whose hostname includes SRV or a client prefix.
Variable
Filter based on a variable defined in this automation. The association dropdown lists every variable created for the current automation — variables from other automations don’t appear here.
Operator | Description |
Contains | Variable value includes the entered string |
Does not contain | Variable value does not include the entered string |
Equal to | Variable value exactly matches the entered string |
Not equal to | Variable value does not match the entered string |
Enter the value to compare against as free text.
Custom field
Filter based on a custom field value on the device.
Select the custom field from the association dropdown. The list shows all custom fields configured in your organization.
Operator | Description |
Contains | Field value includes the entered string |
Does not contain | Field value does not include the entered string |
Equal to | Field value exactly matches the entered string |
Not equal to | Field value does not match the entered string |
Enter the value to compare against as free text.
💡 TIP: Custom field conditions are useful for branching automation logic by client or site — for example, running an action only on devices where a specific field is populated, or skipping an action where a field indicates a known incompatibility.
System variable
Filter on one of Level’s built-in system variables, the same values you can insert into scripts and message fields. Select the variable from the association dropdown, then set the comparison and the value. The full list is in System Variables.
Every system variable has a type, and the type decides which comparisons you get and how you enter the value.
Type | Example variables | Operators |
Text | Device hostname, Device OS, Device group path, Device tag names | Contains, Does not contain, Equal to, Not equal to |
True or false | Device online, Device maintenance mode, Device restart required | Equal to, Not equal to, with a True / False picker for the value |
Number | Device CPU cores, Device memory | Equal to, Not equal to, Greater than, Less than, Greater than or equal to, Less than or equal to |
Date and time | Device last seen at, Device last boot at, Device first seen at, Level time | Greater than, Less than, Greater than or equal to, Less than or equal to, with a date and time picker for the value |
ℹ️ NOTE: The Contains and Does not contain operators ignore case. Equal to and Not equal to compare the whole value and do match case, so use Contains when you only need part of the value to match.
💡 TIP: Variables that hold a list, such as Device tag names and Device private IP addresses, are stored as one comma-separated string. Use Contains to check whether a single tag or address is in the list.
ℹ️ NOTE: Date and time conditions compare against the exact date and time you pick, not a rolling window. For “within the last N days” filtering, use a Last seen (in days) condition instead. If a device has no value for the variable yet, a greater than or less than comparison is not met and the action is skipped.
Type
Filter by device type.
Operator | Description |
Equal to | Device type matches the selected value |
Not equal to | Device type does not match the selected value |
Values: Workstation, Server.
OS
Filter by the device’s specific OS version.
Operator | Description |
Equal to | OS version matches the selected value |
Not equal to | OS version does not match the selected value |
Values are populated from the OS versions present in your device inventory — examples include Windows 11, Windows Server 2022, macOS Sonoma, Debian. Your list reflects what’s actually enrolled.
ℹ️ NOTE: OS values are specific version names, not OS families. To filter broadly by operating system type (Windows, macOS, Linux), use a Platform condition in the trigger instead — or use multiple OS conditions with a separate action copy per platform.
Action status
Filter based on the outcome of a previous action in the same automation run, on the same device. The association dropdown lists all actions that appear before this one in the pipeline.
Operator | Description |
Equal to | Prior action result matches the selected status |
Not equal to | Prior action result does not match the selected status |
Value | Description |
Success | The prior action completed without errors |
Failed | The prior action encountered an error |
Skipped | The prior action was skipped (its own conditions weren’t met) |
💡 TIP: Action status conditions are the primary tool for building conditional logic in automation pipelines. For example: run a script, then use an Action status = Failed condition on the next action to send a notification or create an alert only if something went wrong.
FAQ
Do action conditions evaluate every time the automation runs, or just once? Every time. Conditions are evaluated fresh on each run, against each device being processed. A device that was skipped last run will be evaluated again on the next one.
Can I use OR logic between conditions on the same action? No. Multiple conditions on the same action always use AND logic — every condition must be satisfied. To get OR-style behavior, duplicate the action and apply different conditions to each copy.
What happens to subsequent actions if this action is skipped? The automation continues to the next action. Skipping an action doesn’t halt the run — only a failed action (depending on your error handling settings) would do that.
Can I branch my automation based on whether a script succeeded or failed? Yes. Add an Action status condition to the actions that should run conditionally, and set the value to Success or Failed based on the prior Shell action’s result.
How current are system variable values? They’re read from the device’s record in Level, which updates when the device reports in. A value such as Device restart required can be a few minutes behind the device itself.
Who can configure action conditions? Technicians with permission to edit automations in the relevant group. See Workspace → Permissions for access control configuration.