Last updated: 2025-11-13
The Looping feature enables you to automate repetitive tasks within your workflows by iterating through data sets or executing actions based on specific conditions. This powerful feature allows for intelligent workflow automation without requiring multiple manual configurations.
Availability: This feature is available for Pro and Enterprise Plans.
Modules: Ticket, Change, Problem, Release, and Tasks.
In this article:
Common use cases
Get started with Looping
Add a Loop node to your workflow
You can add a Loop node to your workflow both during the creation and update processes:
Important configuration aspects
When configuring Loop nodes, ensure to follow these rules:
Operational limits
To ensure optimal performance and stability, the following limits apply to Loop nodes.
Loop types
‘For Each’ Loop
The ‘For Each’ loop allows you to iterate through a collection of data, and execute the same set of actions for each item.
Select a data source
When you create a For Each loop, you must specify the data source to iterate over. Supported data sources include:
1. JSON Parser Output
Select the specific array or variable from your JSON Parser output. For example, select "Asset Display ID" from an "Assets" array to iterate through each asset's display ID. The iteration variable represents each individual value or object in the array.
2. Multi-Select and Lookup Fields
Choose a specific multi-select or lookup field from your ticket or change. For example, select a multi-select field containing requested items to iterate through each selection.
Note: Lookup fields do not apply to Problem, Release, Task, or Software User workflows. Only multi-select fields apply to most workflows, with limitations for Software User workflows.
3. Associated Entities
Iterate through associated entities such as Assets out of the box. For other associated entities, leverage the Web Request/API to fetch the data and parse it using JSON Parser.
4. Custom Object records
Iterate over multiple matching records from a custom object, pulled into the workflow via the Reader node.
Configure actions inside For Each loops
Use iteration variables in Actions
Once you set your data source, you can configure a variety of actions that will execute for each iteration.
Placeholder convention
Use the following placeholder format to reference iteration data within your actions: {{L1.\[L1.counter\].data}}
where, L1 represents your Loop node identifier. The iteration indexing starts from zero.
Condition nodes in For Each loops
When adding a Condition node inside a For Each loop, fields from your entity object (such as Ticket or Change) are available for condition evaluation.
You can also use placeholders from subflow inputs (when a subflow is used inside the loop), subflow outputs (when a subflow is positioned before the loop in the workflow), and standard and custom object fields. For condition node, the placeholder from the loop iteration will be “L1.Data”.
Array handling in Conditions
For arrays of strings or numbers, such as an array of strings like \["ram@freshservice.com", " diana@freshservice.com"\], the loop iterates through each string value. Configure conditions using the iteration index or loop variable to evaluate based on the current iteration.
Output limitation: Output from readers returning multiple records cannot be used directly in condition nodes. They can only be used as data sources. This is because of duplication.
Condition paths
If no nodes exist in either the "Yes" or "No" path of a condition, the workflow proceeds directly to the next iteration.
Event and Timer Nodes in For Each loops
Event nodes are not applicable within For Each loops. Timer nodes are not applicable within For Each loops.
Subflows in For Each loops
You can integrate subflows within your For Each loops.
Subflow restrictions
Subflows containing timer nodes cannot be used in scheduled workflows. For scheduled workflows, subflows with both approval and timer nodes cannot be added to loops. If you encounter a restriction message ("Subflows with timer node can't be used in scheduled workflows"), clone the subflow, create a new version, and remove the node which is causing the validation to fail.
Additional node support in For Each loops
Expression nodes
Support placeholders from your workflow's standard object, include the loop's iteration index variable, and reference subflow placeholders as needed.
Reader nodes
Only single-record output configurations can be used inside loops. Multi-record Reader outputs cannot be directly used within For Each loops.
Orchestration and Web Request nodes
Support all the standard workflow object placeholders, include the loop's iteration index variable, and reference subflow placeholders.
JSON Parser nodes
Support the loop's iteration index variable and include subflow placeholders (arrays of strings, arrays of numbers, and object arrays).
‘Do While’ Loop
The ‘Do While’ loop executes a set of actions repeatedly until a specified exit condition is met.
Core configuration
When setting up a Do While loop:
Execution behavior
Node support in Do While loops
Condition nodes
Configure exit conditions similar to standard condition nodes in workflows. Support placeholders from subflow inputs (when used inside the loop) and subflow outputs (when positioned before the loop).
Action nodes
Execute the same actions repeatedly until the exit condition is met. Repeat actions based on the defined time interval. Support placeholders from standard workflow objects and subflows.
Event and Timer nodes
Event nodes are not applicable within Do While loops. The Interval Node replaces the standard timer node and defines the frequency between executions.
Expression nodes
Support standard workflow object placeholders and reference subflow placeholders.
Reader nodes
Only single-record output configurations work inside Do While loops.
Orchestration and Web Request nodes
Support all the standard workflow object placeholders and reference subflow placeholders.
JSON Parser nodes
Support subflow placeholder conventions.
Subflows in Do While loops
Reader node behaviour in Loops
Reader nodes can serve as data sources for ‘For Each’ loops, allowing you to iterate over multiple records returned by a Reader query.
Configure Readers for loop iteration
To use a Reader as a loop data source:
Configuration options
When opening a Reader node for configuration, a new UI displays your multi-record setting. The corresponding radio button is pre-selected based on your current configuration. By default, the option for "Single record return only" is selected.
Backward compatibility
Edge cases and limitations
Approvals inside Loops
Approval configuration
Use case and configuration:
You can implement approvals in loops for two different scenarios.
Scenario 1: Consistent Approvals Across All Iterations
The same approval action executes for every loop iteration. For example, a loop iterates through impacted services or assets in a change record. For each service or asset, an associated owner or CAB must approve. An approval is triggered for each owner or CAB automatically.
Scenario 2: Conditional Approvals
Approval actions vary depending on the iteration data. For example, after retrieving different asset owners in each iteration, different approval paths are triggered based on the asset type, owner, location or other conditions. Each iteration may route to different approvers.
Approval Execution Modes
The approval execution behavior depends on your Workflow Automator settings in Global Settings, specifically when non-blocking approvals are enabled. (For more information on non-blocking execution for approvals, refer to this article).
Non-blocking Approvals Enabled
When non-blocking approvals are turned on:
Non-blocking Approvals Disabled
When non-blocking approvals are turned off:
Looping with Subflows
Subflows provide modular workflow logic that can be reused and combined within loops. By configuring subflows within loops, customers can re-use the loop block itself across multiple workflows.
Subflows within ‘For Each’ loop
Pass iteration data as subflow inputs. Reference subflow outputs in subsequent loop nodes. Restrictions apply to subflows with timers or certain approval configurations.
Subflows within ‘Do While’ loop
Input by passing standard workflow placeholders and loop node placeholders. Output using S1.Key format to reference subflow results in subsequent iterations.
Sync with Sandbox
Source-to-Target sync
When syncing workflows containing Loop nodes from source to target instances:
Sync scenarios
Activity log
Activity log for loop being executed:
Activity log when loop waits for web request response and then resumes:
Delete and restore workflow configurations having loops
Deletion behavior
When you delete a workflow containing Loop nodes:
Restoration process (restoring a workflow from trash)
General restoration
If a workflow with the same name and state was created during the deletion period, a rename request is shown. Workflows are restored in Inactive or Draft state. Workflow execution resumes only after activation and only for new matching events.
‘For Each’ Loop restoration
‘Do While’ Loop restoration
Plan downgrades and retention periods
When customers downgrade their plan to Growth or Starter:
During the 30-day grace period
After the 30-day grace period
Upgrade during the grace period
If customers again upgrade to Pro Plan or higher within the 30-day grace period, everything resumes to normal operation. No additional action is required.
Upgrade after the 30-day period
If customers upgrade after the 30-day grace period, the data in the loop nodes would have been removed by then - so the only option is to delete the loop node and recreate the same.
Key callouts
1. Loop inside subflows is not supported.
2. Loop inside loop is not supported.
3. Naming convention:
1. A loop node’s label cannot be reused in the same workflow.
2. Subflows or other workflows can have the same name as the loop node. 4. Editing a loop configuration would have the below experience:
1. When the workflow is opened in “edit” mode > open the loop node and click edit > this will enable editing for the loop.
2. Opening the workflow normally as read only > when the loop node is opened > only the read only view is supported. 5. Cloning:
6. If the loop encounters an error during execution (including empty values being returned from the data source or the placeholder being resolved wrongly) - only that particular workflow will be disrupted (subsequent iterations will also not resume); subsequent workflows will not be impacted and will be executed as usual.
7. If the timer is the last node in the workflow, and it is configured immediately after a loop:
8. When the loop (a particular iteration) is waiting for an event like web request/orchestration response or approval - after the response is received and the next iteration resumes, in activities it will be mentioned that the “loop has been initiated”. This is to ensure continuity of the loop being called out clearly.
9. When an approval node is configured as the last node inside a subflow, and that subflow is used as the last node inside a loop:
1. The “Loop Completed” activity cannot be logged after the final iteration (in the new approvals process).
2. Recommendations:
1. Do not have approval as the last node inside a subflow.
2. Even if approval has to be the last node inside a subflow - do not have that subflow as the last node within a loop. 10. In the following scenarios, the “Workflow Ends” activity cannot be logged.
1. Approval within a Loop Node:
1. When an Approval node is placed inside a Loop node, and that Loop node is the final node in the workflow. 2. Approval within a Subflow inside a Loop Node:
1. When an Approval node is inside a Subflow, and that Subflow is inside a Loop node, with the Loop node being the final node of the workflow. 3. Recommendations:
1. Do not have approval as the last node inside a loop when the loop is the final node in the workflow.
2. Do not have approval as the last node inside a subflow which is inside a loop - when the loop is the final node in the workflow.
Best practices and tips
Troubleshooting
1. Loop nodes are not appearing in my workflow: Verify whether your plan is Pro or Enterprise.
2. Data source not available for my loop: For Reader nodes, verify the Reader is configured to return multiple records. For multi-select fields, confirm the field exists and supports iteration.
3. Workflow with loop nodes is not executing as expected:
1. Check that all required fields referenced in the loop exist in your instance.
2. Verify subflows linked to the loop are active and have the correct input/output parameters mapped.
3. Ensure Event nodes are not positioned immediately after Loop nodes. 4. Subflow with a timer cannot be added to the loop node: Clone the subflow and remove the timer node. Create a new subflow version without the timer to use in your loop.