Introduction

The Workflow feature in HP Workforce Experience Platform (WXP) is a low-code workflow orchestration capability designed for large-scale IT remediation. It enables IT administrators to deploy automated workflows across thousands of endpoints using a visual, drag-and-drop interface, helping teams shift from reactive ticket handling to proactive remediation.

Dependencies and Prerequisites

Script Requirement for Branching

• Scripts must be tested beforehand. Script output is used for:

  • Branching logic

  • Webhook payloads / query parameters

• Webhook must be tested beforehand. Currently, we support only support JSON inputs, and plain text OR JSON outputs.

Platform and Version Requirements

Ensure the following requirements are met before creating Workflows:

Creating a Workflow

Step 1: Adding a Trigger

Every workflow must begin with a trigger:

1. Log in to WXP. The Home page is displayed.

2. From the left menu of WXP, click Labs. The Labs page is displayed.

3. On the Labs page, scroll to the Workflow section and click Try Workflow. The exiting workflow are displayed.

   

4. Click Add to create a new workflow. The Add workflow dialog box is displayed.  

   

5. In the Add workflow dialog box, you can either create a new workflow from scratch or duplicate and modify an existing workflow.

   

6. When creating from scratch, trigger an event:

   1. Event Trigger (Alert-based): The workflow is initiated when an alert occurs. The available alert options include the existing alerts that are created or provided in the platform.

   2. Schedule Trigger: Administrators can define the date, time, and target groups for the workflow. The Group options displayed are based on the groups created in WXP platform.

   

Step 2: Adding Actions

After adding a trigger, you can add one or more actions to define what the workflow must do.

• Script:  The script options displayed are the pre-existing scripts that are either created in WXP or provided by WXP.

• Webhook: Integrate with 3^rd part systems, such as ServiceNow, Teams, and Slack. Configure your webhook manually or through the Swagger API endpoint URL. Testing is required before the webhook is used in a workflow.

• Device action: A device action can be used to perform driver updates, such as:

  • Deploying all driver updates

  • Deploying only critical driver updates

  • Deploying all or critical driver updates for selected driver categories

Step 3: Adding Branching Logic

Use if/then/else conditions to create advanced logic paths. Branching can be based on the outputs from scripts, webhooks, or driver Updates.

Current Limitations

• Nested branching is not supported

  • A branch placed before or after another branch is treated as separate—not nested

• You cannot add actions after a branch

Time Zone Behavior for Schedule trigger

This behavior only applies to Schedule trigger. When creating a workflow, the scheduled time is set in your (creator’s) time zone. However, execution occurs in the local time zone of each target device. For example, If you schedule a workflow for 9:00 AM PST; the devices in EST will execute the workflow at 12:00 PM EST. This helps to ensures workflows run at the intended local time for each recipient, regardless of where they are located.

Alerts and Activity Behavior for Event trigger

Fleet vs. Device Alerts

Workflow executions triggered by alerts are reflected in the Activity tab of WXP. Activity behavior based on the type of Alert:

• Fleet-level alert: Executions are shown when an alert is triggered across a fleet of devices.

• Device-level alert: Executions are tracked individually for each device

• Note:

  • If an alert is already active before publishing, those devices are included in the workflow audience.

  • If an alert rule changes, that is the “Trigger Conditions” section of the alert rule is  updated, it can trigger new executions.

Editing the Audience

• Editing is supported only for schedule-based workflows that use date-based triggers.

• Editing audience is not supported for event-based workflows after they are published.

Editing Rules

The following rules apply based on the status of the workflow:

1. Workflow is Active (Recurring, Start Time Passed)

• Audience: At this stage, the audience is editable.

• Groups:

  • Adding Groups: If groups are added, they are included in Current execution (if not completed) and Future executions. This action can be viewed in the Activity tab, which shows the user who created the group and the timestamp of group creation.

  • Removal of Groups: If groups are removed, they are removed from the remaining devices in the Current execution and from Future executions. They are not removed from devices where execution is completed. This action is can also be viewed in the Activity tab.

2. Workflow is Active (Start Time has not  Passed)

The audience can still be edited. Any changes that are made will apply to the upcoming run. All actions are logged with user details and timestamp of update.

3. Workflow is Active (One-Time, Start Time Passed)

Audience is locked and  Workflow is finalized.

Viewing Workflow Statuses

You can view the status from the Workflows listing page of WXP.

The following statuses are supported.

Reviewing Workflow KPIs

After a workflow is published, you can access its KPIs by clicking the workflow name on the Workflow List page and then navigating to the Activity tab on the Workflow Details page. The KPIs are displayed under Executions tab.

Reviewing Execution Statuses

After a workflow is published, you can access execution statuses by clicking the workflow name on the Workflow list page and then navigating to the Activity tab. The executions are displayed in a table.

Execution-Level Status (Per Execution)

• In Progress: Same criteria as above

• Completed: Finished or resolved

• Canceled: Workflow canceled before execution

Reviewing Device-Level KPIs

Device-Level Status (Within a Workflow Execution)

Device-level status indicates whether an individual device successfully completed all steps in a workflow or encountered an issue during execution. This is accessed post-publish by clicking the workflow name on Workflow list page > Activity tab > Execution (in the case of a device level alert you will devices treated as an execution).

After a workflow is published, you can access device-level status by clicking the workflow name on the Workflow list page > Activity tab, > Execution. For device-level alerts, each device is treated as a separate execution.

Note: If a device encounters a fatal error at any step, it will not proceed to subsequent steps in the workflow.

Status Types

The following statuses are supported at device level:

Note:

• Device execution results are visible in the Activity tab.

• Executions only appear when they occur

  • Recurring workflows will not show future executions in advance

• Device-level insights help identify:

  • Failure points

  • Offline devices

  • Execution bottlenecks

Workflow Builder Use Cases

1. Creating a ServiceNow Ticket from an Alert

• Scenario: Your organization wants to automatically create a ServiceNow (SNOW) incident when a specific alert is triggered in HP WXP.

• Solution: Use an Event-based trigger (Alert) by selecting the relevant alert. For example: device health, app crash, performance issue)

  • Action: Add a Webhook action  and configure the webhook to integrate with your ServiceNow endpoint. Ensure the webhook payload includes key device details (such as the device serial number) to support accurate ticket creation and tracking. You can dynamically populate these fields using our Variable list which provides access to:

    • Global variables, such as device-level attributes.

    • Step outputs, such as script results or previous action outputs

Using these variables ensures consistent formatting and enables richer, context-aware integrations (such as ServiceNow tickets).

• Outcome:

  • When the alert is triggered, a ServiceNow ticket is automatically created per device.

  • Faster incident response without manual intervention

Note: Ensure webhook payloads are tested in advance to validate field mappings and ticket creation in ServiceNow.

2. Automated Remediation + Ticketing for PowerPoint Crashes

• Scenario: An alert indicates that PowerPoint crashes are impacting a percentage of your fleet. Your organization wants to automatically remediate affected devices and create tickets only for failures.

• Solution: Use an Event-based trigger (Alert). For example, PowerPoint crashes affecting X% of devices.

  1. Action 1: Run a script action to update affected devices to the latest version of Microsoft Office.

     1. Branching Logic (If/Then):

        1. Evaluate the script result:

           1. If Exit Code = 0 (Script Success):

              1. End workflow (issue resolved)

           2. Else (Failed):

              1. Proceed to next step

  2. Action 2 – Webhook (ServiceNow Ticket):

     1. Trigger a webhook to create a ServiceNow ticket, if devices fall under the Else (aka failed condition)

        1. Include:

           1. Device details

           2. Script output (for troubleshooting)

• Outcome:

  • Devices are automatically remediated at scale

  • Only failed devices generate tickets, reducing noise

  • IT teams focus on exceptions rather than the entire fleet

Key Benefits Across Use Cases

• Reduces manual ticket creation

• Automates remediation before escalation

• Minimizes ticket volume in ServiceNow

• Improves response time and end-user experience

Related Resources

For additional information, refer to the Overview of Workflow article.

Contact Us

For any assistance, create a support case or email support@wxp.hp.com.