You can select one of the following trigger types to activate the Start node in a workflow:
Schedule
The Schedule trigger type enables you to automate the execution of the workflow based on a predefined schedule. You can configure the schedule with the following options:
Interval
Under Repeat every, select one of the following time intervals:
Minutes
Hours
Days
Based on your selection, more fields appear to enable you to specify when to run your flow.
Optionally, if you select Hours, you can set excluded time windows when the Schedule trigger won’t run. Under Excluded time windows, click the time picker icon
to exclude times in the From: and To: fields. Click + Add excluded time window to add as many as needed.
Excluded time windows are ideal for avoiding maintenance windows or peak business hours. Note that excluded time windows can’t overlap.
Specific time
Under Specific time, select one of the following recurrences:
Daily. Set a Time and Timezone.
Weekly. Select at least one day of the week, set a Time and Timezone.
Use case examples:
Running a daily health check on all critical servers at 3:00 AM.
Generating a weekly performance report every Monday morning.
Monthly offboarding of temporary user accounts on the last day of the month.
API
Use an API trigger when an external application, service, or script should start a flow. The external system sends a request to Workflows, and Workflows starts the flow identified in the request.
For example, a monitoring system can start a remediation flow when it detects an issue, an HR platform can start a user-provisioning flow, or a custom application can start an IT automation task.
Configure an API Trigger
Open the flow and click the Start node.
Under Trigger type, select API.
The Start node displays the information required to start the flow from an external system:
Flow ID: Identifies the flow that Workflows should start.
Generated cURL request: Shows an example HTTP POST request containing the Workflows endpoint, authorization header, Flow ID, and request body. The external system does not have to use cURL, but it must send an equivalent request.
DEX token: Authenticates the external system sending the request. Replace
dex_tokenin the generated request with a valid DEX token. To create a token, see Create an API Key.
Use the generated cURL request as a reference when configuring the external system that will start the flow.
Pass Data to an API-Triggered Flow
Use input variables to pass information from the external system into the flow. Each input variable defines a value that the API request can send and that later nodes in the flow can use.
In the flow's Start node, go to Input Variables and click + Add.
Add an input variable for each value that the external system will send.
Use the generated cURL request as a reference when configuring the external system. The request body updates automatically to include the input variables.
In the external system, provide each value using the same variable name shown in the generated request.
In later flow nodes, reference the input variables wherever the received values are needed.
Check Values Generated by the External System
The external system, not Workflows, resolves any variables or placeholders used to generate the request values. Workflows receives the values that the external system sends.
Keep the following in mind:
Some values are available only when an actual event occurs. The external system's test function might fail or leave these placeholders unresolved.
Values that generate lists or repeated content might require syntax specific to the external system.
An unresolved expression such as
$(VariableName)indicates that the external system did not replace the placeholder with its value before sending the request.
Follow the template syntax required by the external system. When the test function cannot provide event-time values, verify the configuration using an actual event.
Example: Start a Flow from ControlUp for VDI
A ControlUp for VDI trigger can start a flow by using a Send a RESTful API request follow-up action.
In Workflows, add an input variable for each VDI trigger value that you want to use in the flow.
In the VDI trigger, add a Send a RESTful API request follow-up action. Configure it to send a POST request using the endpoint, Flow ID, authorization header, and request-body structure shown in the generated cURL request in Workflows.
In the VDI notification template body, map each Workflows input variable to the corresponding VDI notification variable.
The VDI ListOfColumns variable can return formatted information for each column involved in a Stress Level or Advanced trigger.
Use ListOfColumns as the value of the matching Workflows input variable. For example, if the Workflows input variable is named column_details, use:
"column_details": "$(ListOfColumns:"Column: $(Column) | Threshold: $(ColumnCrossedThreshold) | Before: $(ColumnValueBefore) | After: $(ColumnValueAfter)")"Use the quotation marks exactly as shown. Do not add backslashes before the quotation marks around the repeated format. Escaping these quotation marks prevents VDI from resolving the ListOfColumns expression, and the unresolved expression is sent instead of the column values.
When the trigger activates, VDI sends the column name, crossed threshold, previous value, and current value for each affected column.
Testing Requests with VDI Trigger Values
Even when the notification-template syntax is correct, some VDI variables are populated only when an actual trigger event occurs. When a request uses these variables, the Test button in the VDI follow-up action might return an error or send unresolved placeholders such as $(VariableName). This does not necessarily mean that the request will fail when the trigger activates. Verify the configuration using an actual trigger event.
For general instructions on configuring a RESTful API follow-up action in ControlUp for VDI, see Using Webhooks as Follow-Up Action. For the available VDI notification variables and their syntax, see Notification Templates.
Manual
Selecting the Manual trigger type means that the workflow executes only when a user explicitly starts it. This is done in the Workflow application’s Flows tab by clicking the actions menu and selecting Run Manually.
Use case examples:
Running a script to onboard a new employee when the HR paperwork is complete.
Executing a diagnostic workflow on a specific machine when a user reports an issue.
Generating an on-demand report.
Listener
The Listener trigger type activates a flow when Workflows receives an alert or event from a supported ControlUp product or third-party service. Select the service, integration, and event or alert type in the Start node. When the selected alert or event is received, the flow runs automatically.
The available event types, filters, and variables depend on the selected service.
Use Azure DevOps Listener
The Azure DevOps Listener allows you to receive real-time updates to ADO work items, and helps you integrate your incident response and ticket-based remediation into the DevOps lifecycle.
To use the Azure DevOps Listener in your flow:
In the Start node, from the Service dropdown, select Azure DevOps.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select an event type.
In the Project Name field, enter a project name.
Under Filter Mode > Parameters, enter a Field name, select a Condition, and enter a Value as needed.
Optionally, under Filter Mode, click WIQL to filter, search, and retrieve specific work items. Enter specific filter conditions as needed. For example:
[System.TeamProject] = 'MyProject', [System.State] = 'Active')Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Use case examples:
Trigger a flow every time a bug in an ADO work item is moved to the "Active" state to immediately notify your on-call team via Slack.
Capture the latest work notes from an ADO work item to automatically update a linked ticket in an external platform like Jira Service Desk, Zendesk, etc.
Use ControlUp One Platform Listener
The ControlUp One Platform Listener allows you to receive alerts from your user devices with ControlUp for Desktops. You don’t need to manually configure ControlUp product integrations.
To use the ControlUp One Platform Listener in your flow:
In the Start node, from the Service dropdown, select ControlUp One Platform.
From the Integration dropdown, select an integration.
From the Alert dropdown, select an alert and click Save. This makes the service’s variables available to use in downstream steps.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
ControlUp One Platform Listener variables display in the following format: {{Start.event.<variable>}}
For example, a variable named “action_type” will display as: {{Start.event.action_type}}
Use Datadog Listener
The Datadog Listener allows you to receive events and incidents from Datadog and use them to trigger workflows.
To use the Datadog Listener in your flow:
In the Start node, from the Service dropdown, select Datadog.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select an event type.
Optionally, use the Alert Type, Priority, Sources, Tags, or Host fields to filter events.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Datadog returns up to 1,000 of the most recent events per poll. To reduce the number of returned events, use filters or shorten the polling interval for high-volume Event Streams.
Datadog Listener variables display in the following format: {{Start.event.<variable>}}
Use Freshservice Listener
The Freshservice Listener allows you to receive ticket events from Freshservice and use them to trigger workflows.
To use the Freshservice Listener in your flow:
In the Start node, from the Service dropdown, select Freshservice.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select Ticket Created or Ticket Updated.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Freshservice Listener variables display in the following format: {{Start.event.<variable>}}
Use Jamf Pro Listener
The Jamf Pro Listener allows you to receive events from your Jamf user devices.
To use the Jamf Pro Listener in your flow:
In the Start node, from the Service dropdown, select Jamf Pro.
From the Alert dropdown, select an alert and click Save. This makes the service’s variables available to use in downstream steps.
Follow the instructions displayed under the alert to setup a webhook in the Jamf settings. You must configure a separate webhook in Jamf for each event that you want to listen to, as Jamf does not support sending multiple events to a single URL via one webhook.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Jamf Pro Listener variables display in the following format: {{Start.event.<variable>}}
For example, a variable named “action_type” will display as: {{Start.event.action_type}}
Use case examples:
Automatic responses to security incidents by generating incident tickets using collected data - no manual user input required.
Service health monitoring and escalation based on diagnostic results from affected systems.
Interactive troubleshooting sends diagnostic options to your IT support team via a chat service, waits for their input, and then automatically applies their selected fixes to the affected systems.
Use Jira Service Desk Listener
The Jira Service Desk Listener allows you to receive real-time updates to Jira issues, and helps you integrate your incident response and ticket-based remediation into your ITSM lifecycle while working within Jira’s REST API capabilities.
To use the Jira Service Desk Listener in your flow:
In the Start node, from the Service dropdown, select Jira Service Desk.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select an event type.
Under Filter Mode > Parameters, enter a Project name, Issue Type, Status, Assignee, and Priority.
Optionally, under Filter Mode, click JQL to filter, search, and retrieve specific work items. Enter specify filter conditions as needed.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Jira Service Desk variables display in the following format: {{Start.event.<variable>}}
For example, a variable named “action_type” will display as: {{Start.event.action_type}}
Use Microsoft 365 Admin Reporting Listener
The Microsoft 365 Admin Reporting Listener starts a flow when Microsoft 365 directory activity events are detected, such as user, group, license, or role changes.
To use the Microsoft 365 Admin Reporting Listener in your flow:
In the Start node, from the Service dropdown, select Microsoft 365 Admin Reporting.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select the directory activity event that starts the flow.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Microsoft 365 Admin Reporting Listener variables display in the following format: {{Start.event.<variable>}}
Use Microsoft Entra ID Listener
The Microsoft Entra ID Listener starts a flow when Microsoft Entra ID directory activity events are detected, such as application, service principal, device, or role changes.
To use the Microsoft Entra ID Listener in your flow:
In the Start node, from the Service dropdown, select Microsoft Entra ID.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select the directory activity event that starts the flow.
Optionally, in Extra OData Filter, enter a Microsoft Graph OData filter fragment to narrow the matching audit log events.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
The connected Microsoft Entra ID application must have the required Microsoft Graph application permissions. Use AuditLog.Read.All for least privilege, or Directory.Read.All. Admin consent is required.
Microsoft Entra ID Listener variables display in the following format: {{Start.event.<variable>}}
Use monday.com Listener
The monday.com Listener starts a flow when monday.com board activity is detected, such as item, column value, or column changes.
To use the monday.com Listener in your flow:
In the Start node, from the Service dropdown, select monday.com.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select the board activity event that starts the flow.
In the Board ID field, enter at least one board ID.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
monday.com Listener variables display in the following format: {{Start.event.<variable>}}
Use Okta Listener
The Okta Listener starts a flow when Okta activity is detected, such as app lifecycle, app assignment, user lifecycle, or group membership changes.
To use the Okta Listener in your flow:
In the Start node, from the Service dropdown, select Okta.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select the Okta activity event that starts the flow.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
The connected Okta integration must use an Okta API token from an admin who can read the System Log, such as a read-only administrator.
Okta Listener variables display in the following format: {{Start.event.<variable>}}
Use PagerDuty Listener
The PagerDuty Listener allows you to receive incident events from PagerDuty and use them to trigger workflows.
To use the PagerDuty Listener in your flow:
In the Start node, from the Service dropdown, select PagerDuty.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select an event type.
Optionally, from the Urgency dropdown, select Any, High, or Low.
Optionally, enter comma-separated PagerDuty service IDs, team IDs, or user IDs.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
PagerDuty only returns triggered and acknowledged incidents when filtering by user, because resolved incidents are not assigned.
PagerDuty Listener variables display in the following format: {{Start.event.<variable>}}
Use ServiceNow Listener
The ServiceNow Listener allows you to receive events from your ServiceNow user devices.
To use the ServiceNow Listener in your flow:
In the Start node, from the Service dropdown, select ServiceNow.
From the Integration dropdown, select an integration.
From the Event Source Table dropdown, select an event source.
From the Event Type dropdown, select an event type.
Optionally, add filters as needed.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
ServiceNow Listener variables display in the following format: {{Start.event.<variable>}}
For example, a variable named “sys_id” will display as: {{Start.event.sys_id}}
Use case examples:
A new incident is opened in ServiceNow for an event triggered by an update.
Escalate remediation issues based on live ServiceNow activity.
Use Zendesk Listener
The Zendesk Listener allows you to receive ticket events from Zendesk and use them to trigger workflows.
To use the Zendesk Listener in your flow:
In the Start node, from the Service dropdown, select Zendesk.
From the Integration dropdown, select an integration.
From the Event Type dropdown, select an event type.
Optionally, add variables as needed.
In any downstream step input field, open the variables dropdown and select Start > event to add variables as needed.
Zendesk Listener variables display in the following format: {{Start.event.<variable>}}
Form
The Form trigger type allows you to activate your flow when a user submits an existing form. The flow is activated automatically based on the input provided in the selected form.
To use Form variables in your flow:
In the Start node, from the Form name dropdown, select the desired form and click Save. This makes the form’s variables available to use in downstream steps.
In any downstream step input field, open the dropdown and select Start to add Form variables as needed.
Form variables display in the following format: {{Start.<form variable>}}
For example, a variable named “User Name” will display as: {{Start.User Name}}
Use case examples:
Onboarding new employees.
Responding to user survey submissions.
Evaluation and remediation of incident reports results.