Overview: Track Loop Count
workflow module (Console)
Console > Workflows > Workflow modules > Overview: Track Loop Count workflow module (Console)
This article provides an overview of the Track Loop Count workflow module in Console.
In this article
Overview
In Console, use the Track Loop Count workflow module to set a maximum number of times a workflow session is allowed to loop an area before the system stops the looping and forces the session down a different path through the workflow.
The Track Loop Count workflow module first tracks and counts the number of times a session loops through a workflow module. This is the function of the Keep Going port.
In the above screenshot, the Track Loop Count workflow module is counting the number of times the session loops through the Webhook module’s Failed port. It will only allow 5 loops, since the Max Loop Count is set to ”5”.
Then, if the configured maximum loop count is reached, the module automatically stops the looping process and sends the session down to the next module, which is the module linked to the Max Reached port of the Track Loop Count module.
In the above screenshot, the Track Loop Count workflow module is configured to allow 5 loops through the Webhook module. But, on the 6th loop, the session will proceed to the Say module through the Max Reached port.
Therefore, the Tracked Loop Count workflow module is commonly used in conjunction with modules that have these types of exit ports: Invalid, Failed, Error, or No Match because these ports require you to design a “fail safe” experience for the module to help resolve data processing failures or errors that can happen, which create workflow session looping.
So, the Tracked Loop Count workflow module is used in tandem with these modules to function as an “override setting” or “safety net” to protect the module from triggering infinite looping within your workflow.
Lastly, another common use case is to use it in conjunction with tagging. This pairing allows you to report on any occurrences of Max Loop Count being reached and then enhance the workflow to decrease these occurrences.
How it works
Suppose that you have a section of your workflow that relies on collecting an email address before the session proceeds.
You prefer to give the customer a few chances to enter a valid response; but you don’t want the system to infinitely loop if no valid result is received.
So, the workflow needs an “error override path” to tell the workflow how to proceed.
Add in the Track Loop Count workflow module here to monitor and tally the number of times a workflow session loops through the Say + Gather, and then it instruct the module on how to proceed if the maximum number of tallies, or loop counts, is reached (i.e. sends the workflow to the module linked to the Max Reached port).
The Track Loop Count workflow module tallies the number of times a session goes through the Say + Gather’s Invalid port. On the 4th loop, it will send it to the Wait Period module.
Use cases
So, it’s frequently used with modules like: Say + Gather, Say + Array, and Say + Intent because these modules are collecting information that is used to determine where to route the session next.
Therefore, use a Track Loop Count module with these modules to better control the number of times a session loops through the invalid route of the module (i.e. attempts to understand the customer’s intent) and to then define where the session is routed after the looping is stopped. Without the Track Loop Count module, the session could loop indefinitely through the invalid pathway (i.e. No Match) as it works to understand the customer’s intent.
There are other modules that analyze or manipulate data that are commonly used with the Track Loop Count module because it gives you a way to create an experience if a failure result happens and to then define how to send the session down through the workflow. Some of these modules include Create Interaction, Insert, Look up, Update Interaction, etc.
Below are some visual use case examples for where to use the Track Loop Count workflow module.
Say + Intent use case
The Say + Intent workflow module has a No Match port, so use the Track Loop Count workflow module to control the number of times it attempts to detect a customer’s intent before it’s routed to the Say module. Here it will go to the Say module on the 4th loop.
Export Report use case
The Export Report workflow module has a Failed port, so use the Track Loop Count Module to control the number of times the workflow session attempts to export a CSV of the report before forcing the session through the Failed path to the End module. Here it will go to the End module on the 3rd loop.
Webhook use case
The Webhook workflow module has a Failed port, so use the Track Loop Count module to control how many times the system attempts to run the API request before it’s forced down the Failed port to the Say module. Here it will be sent to the Say module on the 6th loop.
Max loop count reached reporting use case
Link a Modify Tags module to the Max Reached port of the Track Loop Count module to be able to track the number of times the maximum loop count has been reached. Here it will send the session to the Modify Tags module on the 4th loop to add the Max Reached tag to it.
Visual breakdown
Basics
Label: The Label field is where you define a custom name for the workflow module. This can make it easier to see what the module is doing from the workflow editor workspace, and this is how the module is referred to in reporting.
Tracking
Max Loop Count: The Max Loop Count field is where you define the maximum number of times the workflow session can loop before the looping is stopped and routed through the Max Reached port. Values for this field are in whole numbers. For example, if you want to allow session to loop six times before continuing onward, then enter a “6” into this field. Then, the session will be forced forward on the 7th loop.