Introduction

This article walks through building an automation from scratch. The example is a Windows patching automation that runs on a schedule, installs Windows updates, upgrades third-party apps, and creates an alert for each type of failure.

Every concept here applies to any automation you build — swap in a different trigger, different actions, and different conditions for your own use case.

Plan Before You Build

Before clicking + Create automation, nail down three things:

What triggers it? A schedule, a device event, a tag change, a webhook? This automation uses a recurring schedule for hands-off patching.
Which devices does it target? Trigger conditions scope the run — by platform, device type, group, OS version, or other attributes. Here, a Platform = Windows condition on the scheduled trigger limits it to Windows devices.
What happens when something fails? Should the pipeline stop or keep going? Should anyone be notified? This automation captures action output in variables and uses conditional alerts so failures surface without stopping the whole run.

Building Patching Automation

Step 1: Create the Automation

Navigate to Automations in the sidebar.
Click + Create automation in the top right.
Name it Windows Patching.
Click Create.

The automation opens in View mode with an empty pipeline. Nothing runs until you add a trigger. Switch to Edit mode by clicking Edit in the top right.

Step 2: Add the Install Windows Updates Action

In the actions area, click + Add an action.
Browse to Security → Install Windows Updates, or search for it.
Configure the update delay settings:

Update type	Setting
Critical updates	7 day delay
Security updates	Update immediately
Definition updates	Update immediately
Update rollups	7 day delay
Service packs	14 day delay
Tools	7 day delay
Feature packs	14 day delay
Updates	7 day delay
Upgrades	7 day delay
Drivers	7 day delay

Leave Reboot after updates (when required) set to No.
Leave Loop until complete set to No.

Now configure failure handling and the output variable under Additional options:

Set On action failure to Suppress and continue.
Set Retries to 2.
In the Output variable field, created a variable called PatchingStatus.
Click Save.

Why these settings: Suppress and continue means a patching failure on one device doesn't halt the pipeline — subsequent actions still run. The output variable captures the result of this step so a later Create Alert action can check whether it failed. Two retries give transient failures a chance to recover before the step is marked as failed.

Step 3: Add the Upgrade 3rd Party Applications Action

Click + Add an action.
Browse to App management → Upgrade winget package.
Leave Packages set to All available packages and Excluded packages set to No excluded packages.

This action uses winget to upgrade third-party software. It only makes sense on workstations — add a condition to restrict it:

In the Conditions section, add a condition for Type, set the operator to Equal to, and select Workstation.

In the Additional options section:

Set On failure to Suppress and continue.
Set Retries to 2.
In the Output variable field, create a variable WingetPatchStatus.
Click Save.

ℹ️ NOTE: Devices where Type ≠ Workstation skip this action entirely and show Skipped in the run history — that's expected, not a failure.

Step 4: Add the Windows Patching Failed Alert

Add a Create Alert action that only fires when the Install Windows Updates step failed.

Click + Add an action.
Select Level → Create alert.
Configure the alert:
- Title: Windows Patching Failed
- Description: Level was unable to patch endpoint after multiple attempts.
- Severity: Warning
- Custom payload: {{PatchingStatus}}

The {{PatchingStatus}} variable attaches the output from the Install Windows Updates step to the alert. When you review the alert later, the payload shows what actually happened on that device.

In the Conditions section, add a condition:
- Step: Install Windows Updates
- Operator: Equal to
- Value: Failed
Leave On failure as Fail pipeline and Retries at 0.
Click Save.

This action now only fires on devices where patching failed. Every other device skips it.

Step 5: Add the Windows 3rd Party Patching Failed Alert

Same pattern as Step 5, but for the winget step.

Click + Add an action.
Select Level → Create alert.
Configure the alert:
- Title: Windows 3rd Party Patching Failed
- Description: Level was unable to patch some 3rd party software on this endpoint after multiple attempts.
- Severity: Warning
- Custom payload: {{WingetPatchStatus}}
In Conditions, add: Step Upgrade 3rd Party Applications status Equal to Failed.
Leave On failure as Fail pipeline and Retries at 0.
Click Save.

Step 6: Add Triggers

Every automation can be run manually. Add a scheduled trigger to also run it automatically on a cadence.

Add the Weekly Trigger

Click + Add a trigger again.
Select Scheduled → Weekly.
Set the schedule to Monday and Friday at 12:00 AM.
Click Save.

Now scope the scheduled trigger to Windows devices only:

Click the Scheduled → Weekly trigger to open its detail panel.
In the Conditions section, add a condition.
Select Platform, set the operator to Equal to, and select Windows.
Click Save.

Once a trigger has a condition applied, its pipeline card shows an orange IF badge. An orange (x) badge on any step means that step is using a variable. You'll see both appear as you build.

Step 7: Exit Edit Mode

Click Done in the top right to exit edit mode.

The automation is now Active — the Weekly trigger is live and will fire next on its scheduled day. The status badge in the header updates to Active.

How the Pipeline Runs

When the scheduled trigger fires on Monday or Friday at 12 AM:

Level evaluates the trigger condition — Windows devices only
Matching devices enter the pipeline
Install Windows Updates runs with up to 2 retries on failure; output is captured in PatchingStatus
Upgrade 3rd Party Applications runs next; non-workstation devices skip this step; output is captured in WingetPatchStatus
Windows Patching Failed evaluates its condition — fires only on devices where Install Windows Updates failed, attaching the PatchingStatus output to the alert
Windows 3rd Party Patching Failed does the same for the winget step

Every device runs through all four steps. The conditional logic on each action determines what actually happens per device.

💡 TIP: After a run, open the History tab and click any device row to see per-step outcomes (Success, Skipped, Failed) and duration. Click the > caret on any step to expand its output inline, or the → arrow to navigate to the full run detail.

FAQ

Does the scheduled trigger run on devices that are offline at 12 AM? Yes — offline devices are queued and the run starts when they come back online. Add a Status = Online condition to the Weekly trigger if you want to skip offline devices entirely.
Can I run this automation on demand without waiting for the scheduled day? Yes — every automation supports manual runs. From the automation's pipeline view, click + Add a device to run it immediately against specific devices, or use the Actions menu on the device listing to run any automation against a device directly.
Why does Upgrade 3rd Party Applications have a Type = Workstation condition? Winget is a Windows package manager typically found on workstations. The condition prevents it from running on servers where winget packages aren't expected, which avoids spurious failures on those devices.
The alert actions have "On failure: Fail pipeline" — won't that stop the run? Only after the alert step, which is the last meaningful action in the pipeline. The two patching steps use Suppress and continue so their failures don't block the alert steps from running. If the Create Alert action itself fails, you'd want that flagged — so Fail pipeline is the right setting there.
Can I adjust the update delay settings later? Yes. In view mode, click the Install Windows Updates action to open its detail panel, then click Edit act. to reopen the configuration. Adjust and save.
Who can run this automation manually? Any technician with access to the devices being targeted. Group-level permissions control which technicians can manage which device groups. See Workspace → Permissions for details.