Skip to main content
All CollectionsAutomations
Automation Triggers
Automation Triggers

Level has a versatile set of triggers to initiate workflows across managed devices.

Updated over a month ago

Manual Trigger

Every automation will have this trigger (whether selected or not). This means that devices can be manually added to any automation pipeline. This trigger has no editable parameters.


Scheduled Triggers

There are two types of scheduled triggers, Weekly and Monthly. These triggers will match devices on the recurring intervals, in either weekly or monthly frequencies. Additionally, these triggers have a conditions section where device attributes can be used to narrow down the scope of what matches the trigger.


Device Triggers

New Device Detected

This trigger will detect when an agent has been installed on a new device and it has checked in to Level. This trigger will wait for 1 minute before adding the device to the automation in order to give the new device enough time to report on all of its characteristics.

This is useful for assigning tags as soon as a device checks in, or checking for security posture once a device goes into management.


Device Enters Group

This trigger will detect when a device has been added to a Level group. This is useful when organizing agents into departments, or clients. This way when a device is moved to a department or client folder, then certain applications could be installed, or other required settings could be applied.


Device Leaves Group

This is the opposite of Device Enters Group, when a device is removed from a Level folder this trigger will be matched. This is useful if devices need to be off boarded once removed from a department or client group. Software, settings, and credentials could be removed.


Tag Triggers

Tag Applied

This trigger will match when a Level tag is added to a device. This is useful when tags are used to deploy specific software. For example, when the "Office" tag is applied to a device, then install Office! Only one tag can be chosen per condition.


Tag Removed

Just like the Tag Applied trigger this will match devices when a Level tag is removed from a device. An example use case would be when a licensed software tag is removed from the device, that the action of the automation could be to uninstall the software.


Other Triggers

Web Hook Trigger

A web hook will trigger when the URL is accessed. Upon saving a web hook trigger, a random URL will be generated. An optional (but recommended) option to require an authorization header is also available to ensure that the URL is not accessed by unauthorized parties. The condition field is required to determine which agents should be added to the automation pipeline.

This is useful for integrating other tools into Level. For example a ticketing system could trigger diagnostics on devices.


Additional Options

All triggers except "Manual Only" have additional common parameters:

Condition (Required Field)
This field is used to determine which devices will be matched when the trigger is activated. Be specific with the condition so that only desired devices will be matched and added to the automation pipeline. In most cases "All devices" is too broad and not likely the desired scope.
โ€‹
When more than one condition is selected, all the conditions must be met in order to match. For more details on conditions, see the Conditions section in Automation Actions.

Trigger Name (optional)
This field will replace the default name of the trigger

Enabled (optional)

When a trigger is disabled, it will not be used to match conditions.


Conditions

Conditions are mandatory on triggers to define the initial set of devices.

Conditions are conjunctive, meaning that when multiple conditions are applied to an action, all conditions must be met for the action to execute on a device. For instance:

  • If one condition specifies "Platform equals Windows" and another specifies "Tag equals Server," only devices that are both Windows platforms and tagged as Servers will match.

This ensures precise control over where and how actions are applied, enhancing targeted device management.

Did this answer your question?