Managing Workflows in DEX Manager Plus
The Workflows feature in DEX Manager Plus lets IT administrators automate routine endpoint management tasks on a visual, logic-based canvas. A workflow checks real-time device conditions and runs actions based on rules you define.
Use workflows to restart endpoints based on uptime or update status, prompt users before cleaning up unused files, or notify IT teams of threshold violations.
Working with workflows happens in two stages: you build the automation logic here in Workflows, then run it on your devices by creating a deployment in the Deployments module. This page covers the first stage.
- You must have the Workflows role to create, edit, and deploy workflows.
What Is a Workflow?
A workflow is a logic-driven automation that responds to device conditions with predefined actions. It works as a decision tree: every step is a stage (a condition, action, delay, or message) shown visually on the canvas. A workflow starts at a Start node, flows through connected stages, and every path ends at an End node so the logic terminates cleanly.
Workflows are non-linear: each stage runs only if its conditions are met, and branching lets you define different outcomes within the same workflow. Some stages (such as Engage) are interaction- or time-based, while others (such as Remote Action or Restart) perform system-level operations. You design a workflow around a goal, such as remediating a specific issue or preparing systems for an upgrade, so the structure follows whatever outcome you need.
Open the Workflows Page
To open Workflows, go to DEX in the top navigation bar and click Workflows.
The Workflows page lists every existing workflow with its name and description, status (Active/Inactive), last modified time, creation method (Manual/Extension), and author and creation details. Click + Create Workflow to build a new one in the visual editor.
Workflow Components Reference
A workflow is assembled from the following components. Each one is configured in the right-hand pane with properties such as variable names, thresholds, recipients, durations, or scripts.
| Component | Description | When to Use |
|---|---|---|
| Sensor | Retrieves real-time data from managed devices (e.g., uptime, disk space, app activity). | To collect input required for evaluation. |
| Switch | Evaluates sensor data using logical conditions. | To branch workflow execution based on the input. |
| Case | Defines a condition within a switch (e.g., “> 5 GB”). | To create multiple paths for different outcomes. |
| Remote Action | Executes a system-level task via predefined script. | To remediate issues or enforce actions on the device. |
| Engage | Displays a prompt or message to the end user. | When user confirmation or visibility is required before continuing. |
| Send Mail | Sends an email notification to selected recipients. | To alert administrators or teams about execution status. |
| Delay | Pauses the workflow for a defined duration. | When waiting is necessary between actions. |
| Restart | Restarts the target device. No configuration required. | When rebooting the system is part of the response. |
| End | Terminates a branch of the workflow. | Required to complete all paths. |
How to Create a Workflow
Click + Create Workflow to launch the canvas. Drag the components you need onto it, connect them from the Start node through to an End node on every path, and configure each stage in the right-hand pane.
Begin by defining the objective, then decide what condition to monitor (Sensor), how to evaluate it (Switch and Case), and what response is appropriate (Remote Action, Engage, Restart, and so on). There is no mandatory sequence. Connect stages in whatever order produces the outcome you want.
Variables in Workflow
While building a workflow, you can use three types of variables to drive your logic:
- Device Properties: Built-in device details—such as network, disk, and battery readings—that DEX Manager Plus can collect from a managed endpoint once you configure the device property in the workflow.
- Sensor fields: Device data collected through sensors, which you can reference directly without adding a Sensor stage.
- Previous stage outputs: Values produced by earlier stages in the same workflow, such as a user’s response from an Engage stage.
You can evaluate any of these in a Switch to branch the logic, or reference them in later stages such as Engage or Send Mail. Type $ in a supported field to insert a variable; the picker lists available variables grouped by category (Disk, Battery, and so on) with their data type.
For details on each variable type, how to use them across workflow stages, and the full list of available device properties, see Device Properties in DEX Workflows.
Example: Clean Up Disk Space When It Runs Low
- Sensor: Get disk space usage from the device.
- Switch: Apply a condition to evaluate available disk space.
- Case 1, Less than 20%: Remote Action performs disk clean-up to free space > End.
- Case 2, Greater than 20%: End (no action needed).
- Case 3, Default: End (handles any unexpected value).
Each branch evaluates disk space so that clean-up runs only when storage is critically low. Once built, save the workflow. To run it on your devices, create a deployment from the Deployments module, a separate area of the product where you control execution across device groups.
Common Workflow Patterns
| Pattern | Description |
|---|---|
| Evaluate and act | Check a condition, then apply an action if matched (e.g., “If CPU > 80%, stop the process”). |
| Prompt the user first | Inform or prompt the end user before making changes (e.g., “Ask before clearing files”). |
| Multi-branch logic | Evaluate several conditions and respond differently per outcome (e.g., “If X, do A; if Y, do B”). |
| Notify and conclude | Send a status update to admins, then end the flow (e.g., “Send Mail > End”). |
Best Practices
- Use descriptive labels for each stage to keep workflows readable and easy to collaborate on.
- Always define a default case in switches to handle unexpected input.
- Use Engage stages sparingly to avoid excessive prompts to end users.
- Add a Delay only when needed, for example before a restart, after informing the user.
- Test workflows on a pilot group before deploying organization-wide. Pilot deployments are created and managed from the Deployments module.