Workflow: Loop until condition is met

Looping blocks make it easy to work with “blocks” of actions, which are all linked together and organized in a group. You can create a looping block with the Workflow: Loop until condition is met action.

This block replaces the functionality of the Workflow: Reopen tasks and reset dependent tasks action. Existing Workflows still using the action may continue to do so, but new Workflows must use the new looping block for similar functionality.

Use case

This block is used to repeat a series of actions until a condition is met. A common use case is repeating a Web API call until a specific status code is returned.

You can also use this action if you need to redo or resubmit work after a review or rejection, like with invoice processing, or a legal contract review, where work must be redone and a change is needed.

This action is not used to iterate through a list of items, like a table or Excel file—it’s best to use the Excel: Start Process for Each Row or Tables: Start Workflow for Each Row actions in that case.

How to configure this action

This action requires a Stop condition. The stop condition is the “break” condition, or the condition that decides when to stop the loop. Without a stop condition, the looping block will loop until the Maximum loops is met.

The action outputs a useful Number of Loops Completed field, which can be helpful to include in the condition.

How to set up a repeating loop with a counter

With the looping block, no counter is needed as the Number of Loops Completed output field keeps a running count of the loops. If you want to create your own counter, for instance if you want to count from a different starting number, you can set one up manually:

There are a number of ways to set up a loop counter. The easiest is to use the Numbers: Perform basic math action as the first action of your loop. You can use this action to add 1 to the output of itself every loop, effectively incrementing a counter by 1 each loop.

Just set the Calculation field to add 1 to the output the Output. This is similar to saying Counter++ in Javascript.

Fields for this action

• Stop condition

  • Enter the condition for when to stop the loop. At the start of every loop the stop condition is checked, if the condition is met, the loop is stopped and the block is marked as complete.

  • When the condition evaluates to true, the loop will stop.

    

  • See the condition options article for more information on setting conditions in PagerDuty Workflow Automation.

• Maximum loops

  • To protect against infinite loops, enter a maximum number of times to allow the loop to start, up to 10,000. If no limit is set, the maximum loops will be 1,000.

  • The default is true/blank, which will reopen all downstream tasks, even if optionally dependent on the task (using Start after any of these tasks are completed).
  • If false, those optionally dependent tasks will not reopen. This is an optional field.
  • 💡   Tip: An optionally dependent task is one that could be triggered by 1 of many tasks, using the Start after any of these tasks are completed dependency.

• Output field prefix

  • To help keep output fields organized, choose an output field prefix to add to the beginning of each output field name as this action may output more than one field.

What will this output?

The looping block outputs a helpful Successful Instances Table ID field, which is useful for reviewing all the completed loops.

This action may generate multiple fields. To help keep output fields organized, the prefix above will be added to the beginning of each of the output field names, separated by two dashes. Each field will result as:{{output-field-prefix--output-field}}.

Output fields for this action

• Number of Loops Completed

  • Tracks the number of loops completed. A failed instance still counts as a “loop completed”.

• Successful Instances Table ID

  • Stores the table that logs each successful loop. Each successful run is a row in the table. The fields of each run are the columns of the table—including the Instance status, Process name.

  

• Failed Instances Table ID

  • The table for all failed loops. Includes the Job ID and Error Message.

• Parent Run ID

  • The ID for the Workflow the loop is included in. IDs make it easy to reference specific objects. To use a Workflow ID, see I have a Workflow ID, how do I access them?.

Get help with a problem or question

If something’s not working as expected, or you’re looking for suggestions, check through the options below.