Configuring flow controls

Condition flow control

The Condition flow control 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.

  • 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

Wait flow control

The Wait flow control lets you pause a workflow and wait for either a period of time or an API call from an external system. This is helpful when the system has to wait for something that it does not have control over.

There are two types of Wait:

• Time delay

• API listener

Time delay

When time delay is selected and configured, the workflow will pause and wait for the specified time and then automatically continue once the time has elapsed.

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

• Value: Set the delay time in minutes or hours. The workflow will pause for this amount of time before it continues to the next step. The maximum supported delay period is 14 days.

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