Configuring flow controls

Configure Flow controls to drive workflow progression and decision logic based on values collected by the workflow or Nexthink data. These are the available Flow controls:

• Condition

• Repeat

• Wait

• End block

Condition flow control

The Condition block enables the branching of workflows based on values 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.

• The Else branch, added by default when creating new conditions, is optional. The Else path runs whenever none of the defined conditions are met, ensuring the workflow continues without error.

• If a condition has no Else branch and none of the defined conditions are met, the condition will end with a “Default condition” error, and the workflow will stop running.

• The values that the conditions evaluate:

  • Thinklet outputs

    • Remote action outputs

    • Campaign responses

    • Service/API outputs

    • Workflow parameters

  • Database objects properties and their manual custom values: device, user

  • 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.

The system does not filter the list of available operators based on the allowed options for a given data type.

• 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 user or device-specific attributes.

  • Select the source and value of the dynamic data you want to evaluate.

  • Select the operator.

  • Select the value to compare against. Choose Custom value to enter a fixed reference value.

  • Add as many conditions as you need.

• Else: By default, the Else branch will be added to your conditions. Unselect it if you prefer the workflow to end with an error when none of the defined conditions are met.

• 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.

Only one Repeat control is allowed per workflow.

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.

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.

Random time delays help avoid overloading external systems—such as APIs—by preventing all workflow instances from executing simultaneously.

Dynamic time delays to adapt workflow pause behaviors based on dynamic inputs. Refer to Creating workflows documentation for a use case of dynamic time delays in a Wait thinklet.

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.

To use the Wait - API listener, ensure the external system knows about the execution and workflow it will interact with.

Send this information using the {{sys.workflow.executionId}} and {{sys.workflow.workflowId}} variables through a Service/API thinklet. The 3rd party system will then record this information to interact with the workflow. See the format system value example of how to use these values here.

End block

The End block enables you to define and report the final workflow outcomes.

When the workflow reaches an End block, the system logs the chosen Outcome and Outcome details. These execution results become available in:

• NQL data for queries.

• Corresponding Workflow dashboard, including KPIs.

Converge several branches into the same End block when they should report the same final outcome.

• 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): Description of what happened during workflow execution, combining free text with {dynamic values} collected during the run. Keep it concise, especially if used in dashboards. Available in NQL and in the Workflow dashboard.