Configuring flow controls
Condition flow control
The Condition block allows the branching of workflows based on values that have been collected by the workflow or Nexthink data. The system evaluates a condition only once, at the point the workflow execution reaches it.
Conditions accept only one exit point, parallel processing is not supported by Workflows.
In the event that a condition has no valid exit point, the workflow will stop running.
The values that the conditions can evaluate are:
Thinklet outputs
Remote action outputs
Campaign responses
Service/API outputs
Workflow parameters
Database objects
device
user
Custom values
Conditions compare values using the following operators:
Is
Is not
Greater than
Less than
Greater than or equal to
Less than or equal to
Contains
Does not contain
Is empty
Is not empty
Name: Enter a unique name for the condition flow control.
ID: The system generates the ID automatically based on the name.
Description (optional): Describe the purpose of the condition and what it does. This information is useful for other users of the workflow who may not be familiar with it.
Add condition: Add a condition to the condition flow control. You can use manual custom fields for condition values to drive workflow decision logic based on
userordevice-specific attributes.Enter a unique name. This name appears on the canvas and in the NEAL script.
Select the source and value for the condition.
Select the operator.
Select the source and value to be tested against.
Add as many conditions as you need.
Click Done to commit the changes.
Once branches appear on the canvas, thinklets and other flow control blocks can now be added underneath them.
Repeat flow control
The Repeat flow control lets you loop a group of actions, enabling retries, delays, and conditional exits. It's useful for:
Retrying steps that might fail due to network issues or temporary errors.
Waiting for asynchronous events, such as user confirmation or system updates.
Repeating user interactions or actions with controlled timing.
When you use a Repeat block, it executes all actions inside the block multiple times until one of the defined exit conditions is met.
Configuring exit conditions
The Repeat block supports several types of exits. Each exit must be correctly connected in the workflow to function as intended:
Default exit: Indicates a successful or completed state. This must be connected to a condition inside the Repeat block and followed by an exit branch with subsequent actions after the loop.
Exit after X times: Automatically triggers when the loop reaches the defined maximum number of repetitions. This exit only requires a branch after the Repeat block and doesn’t depend on any conditions inside the loop.
Repeat after X minutes/hours: Sets the delay between loop iterations. This condition must be linked to a branch inside the Repeat block and causes the loop to pause and repeat after the specified time.
Custom exits: One or two optional exit conditions that end the loop early based on specific criteria. These should be connected to a branch inside the Repeat block.
See the example below to learn how to correctly link all exit branches
Name: Enter a unique name for the Repeat flow control.
ID: The system generates the ID automatically based on the name.
Description (optional): Describe the purpose of the Repeat loop and what it does. This information is useful for other users of the workflow who may not be familiar with it.
Exit after: Set the maximum number of repetitions. The loop stops when this number is reached. The maximum is 10.
Repeat after: Set the delay between loop iterations. The workflow pauses for this amount of time before retrying the block. You can enter the value in minutes or hours.
Add custom exit: Define one or two custom exits. These are triggered when a condition inside the loop is met.
Only one Repeat control is allowed per workflow.
Wait flow control
The Wait flow control lets you pause a workflow before continuing to the next step. Use it to:
Delay actions for a defined period.
Wait based on user input or conditions.
Spread workload to avoid API throttling.
Coordinate with external systems via API.
Name: Enter a unique name for the Wait flow control.
ID: The system generates the ID automatically based on the name.
Description (optional): Describe the purpose of the Wait and what it does. This information is useful for other users of the workflow who may not be familiar with it.
Type: The Wait thinklet supports two kinds:
Time delay
When selecting Time delay, the workflow pauses for a specified period, then automatically resumes. You can choose from three time options:
Fixed: Set a constant wait defining a static duration. The maximum supported delay is 14 days.
Dynamic: Use the output of a previous thinklet or workflow parameter to dynamically define the wait time. When configuring:
Select the Thinklet or workflow parameter that provides the delay value.
Depending on the case, choose:
Status for remote actions thinklets.
Selected action ID for user input, for example, responses from campaigns or message thinklets.
Select a specific workflow parameter value.
Define the time unit coherent with the expected output of the previous thinklet or workflow parameter.
Random: Set a random delay range.
API listener
When you select API listener, the workflow pauses and listens for an API call being made to the Trigger WaitFor Event workflow endpoint. Refer to the Workflow API documentation for more information.
Configure up to five outputs to capture data from the external system making the call to Nexthink. Use these outputs to either make a branching decision with a condition in the workflow or to provide input information into subsequent thinklets.
Name: Enter a unique name for the Wait flow control.
ID: The system generates the ID automatically based on the name.
Description (optional): Describe the purpose of the Wait and what it does. This information is useful for other users of the workflow who may not be familiar with it.
Type: Select the type of Wait required.
Timeout: Set the timeout in minutes or hours. This dictates how long the workflow waits for the desired API call. When the timeout limit is reached, the workflow enters a failed state and stops processing.
Outputs: Configure up to 5 outputs, which are collected from the API call being listened for. The ID of the output will be used for the parameters in the body of the call made to the Trigger WaitFor Event workflow endpoint.
End block flow control
The End block is the place where you can define workflow outcomes. When the system executes the workflow logic and it reaches the End block, the outcome and outcome details are stored and available to query with NQL. While it is possible to link a few branches to the one End block, use this option if they should report the same End outcome.
Use the Outcome and Outcome details fields to retrieve detailed information about workflow executions and display them as KPIs in dashboards.
Name: Enter a unique name for the End block.
ID: The system generates the ID automatically based on the name.
Description (optional): Describe the expected outcome of the workflow at this point in the logic tree. This information is useful for other users of the workflow who may not be familiar with it.
Outcome: Select from a fixed list of outcomes the one that best describes what happens at this point:
Action taken
No action taken
Failure
Other
Outcome details (optional): Describe what happens when the workflow reaches the End block. The character limit for this field is 64 characters. Nexthink recommends keeping this description concise in case the information is used in dashboards.
Last updated
Was this helpful?