Introduction

Run a saved script on a device as part of an automation. Supports PowerShell, Bash, Python, and other languages. If your script needs data from outside itself — like a custom field value or an automation variable — you can map that in without modifying the script logic.

⚙️ Prerequisites

A saved script must exist in your script library, or you can create one inline. See Scripts for how to create and organize scripts.
An automation must exist before adding actions. See Getting Started with Automations if you haven't set one up yet.

Run Script Action

From the automation pipeline in edit mode, click + and select Run script from the System category.

The action panel opens showing the Script field and two buttons: an external link icon to browse your saved scripts, and Create script to write a new one inline.

Selecting a Script

Click the external link icon next to the Script field to open the saved script picker. Scripts are organized into folders — expand any folder to browse its contents, or use the search field to find a script by name.

Creating a Script Inline

Click Create script to write a new script without leaving the automation editor. The script editor opens as a side panel.

Configure the following:

Script name A descriptive name for the script. It will be saved to your script library and available for use in other automations.

Language The scripting language for this script.

Supported languages: Ansible, Bash, Go, osquery, PowerShell, Python, Zsh.

Timeout (in seconds) How long Level waits for the script to complete before marking it as failed. Default is 100 seconds.

Run as The account context the script runs under.

Option	Behavior
Local system	Runs as the SYSTEM account — elevated, no user context
Current user	Runs as the currently logged-in user — useful for user-context operations like applying wallpaper, configuring user settings, etc.

Write your script in the code editor. Click {x} to reference variables and custom fields inline in the script. When finished, click Create script to save and attach it to the action.

Script Variables

Script variables are named output slots defined in a script's Variables tab. The script writes a value to a script variable during execution, and the mapping in the action panel determines which automation variable stores that value — making it available to subsequent actions and conditions in the pipeline.

ℹ️ NOTE: To pass data into a script — device context, custom field values, system info — use system variables or custom fields via the {x} picker in the script editor. Script variables are for capturing output, not supplying input.

When a script with defined variables is selected, a Script variables section appears in the action panel.

To map a script variable to an automation variable:

In the Script variables section, find the script variable you want to capture.
Open the Automation variables dropdown on the same row.
Select an existing automation variable, or click Create new variable.

When the script runs, the value it writes to that script variable is stored in the mapped automation variable and carried forward through the pipeline. See Automation Variables for the full reference on creating and using automation variables.

ℹ️ NOTE: The Script variables section only appears when the selected script has at least one variable defined in its Variables tab. Scripts without variables don't show this section.

Managing Script Variables

Script variables are defined in the script itself, not in the action panel. Open the script editor and navigate to the Variables tab to add, edit, or remove them.

Capturing Script Output

There are two ways to capture a value from a script and make it available to subsequent actions in the pipeline.

Inline variable syntax

Embed this syntax anywhere in your script output to set an automation variable to a specific value:

{{variable_name=value}}

Level's agent parses the script output for this pattern as the script runs. All other output — logs, status messages, anything else — passes through untouched. See Set Variables Directly from Scripts for more detail and examples.

This is useful when you need a targeted value from a script that also produces other output. The variable must be created in the script variables tab.

Example (PowerShell):

# Get local IP address
$ip = (Get-NetIPAddress -AddressFamily IPv4 |
       Where-Object {$_.IPAddress -ne "127.0.0.1" -and $_.InterfaceAlias -notlike "*Loopback*"} |
       Select-Object -First 1 -ExpandProperty IPAddress)

# Log it normally — this line is ignored for variable purposes
Write-Output "Detected local IP address: $ip"

# Set the automation variable
{{local_ip=$ip}}

After this script runs, local_ip holds the IP address and is available to every subsequent action and condition in the pipeline after mapping.

Assign full output to a variable

In Additional options, use Assign action output to variable to capture the script's entire stdout into an automation variable. This works for any script without requiring any changes to the script itself — but captures everything the script outputs, not just the value you need.

💡 TIP: Use the inline {{variable=value}} syntax when your script produces other output you don't want polluting the variable (logs, status messages, etc.). Use Assign action output to variable when the script's only output is the value you want to capture.

Exit Codes

Level uses the script's exit code to determine whether the action succeeded or failed.

Exit code	Result
`0`	Action marked as successful
Non-zero (e.g. `1`)	Action marked as failed

Your On action failure setting in Additional options controls what happens next — whether the pipeline stops or continues.

Make sure your scripts exit explicitly with the appropriate code. If a script exits 0 after encountering an error it didn't handle, Level will treat the action as successful.

Conditions

The Conditions section lets you restrict when this action runs based on device attributes or the outcome of a previous action.

See Action Conditions for the full reference on condition types, operators, and values.

Additional Options

Expand Additional options for action name, failure behavior, output variable assignment, retries, and the enabled toggle.

See Actions Overview for the full reference on additional options available on every action.

FAQ

What's the difference between Run Script and Shell? Run script executes a saved script from your library — the script is version-controlled and reusable across automations. Shell runs an ad-hoc script written directly in the action panel. Use Run script when the same logic needs to be shared or maintained; use Shell for one-off inline commands.
Can the script write output that other actions can read? Yes — two ways. Define script variables in the script's Variables tab and map them to automation variables in the action panel; values written to those variables during execution carry forward through the pipeline. Or use Assign action output to variable in Additional options to capture the script's full stdout directly into an automation variable without additional mapping. You can also use the inline {{variable_name=value}} syntax to set a script variable mid-execution — it still needs to be mapped in the action panel to become an automation variable. See Capturing Script Output above for details.
What happens if the script times out? The action is marked as failed. The On action failure setting in Additional options controls whether the pipeline stops or continues.
Who can add or modify Run Script actions? Technicians with permission to edit automations in the relevant group. See Workspace → Permissions for access control configuration.