Overview: Subroutine and Return workflow modules (Console)
This article provides overview of the Subroutine and Return workflow modules in Console.
In this article
Overview
The Subroutine and Return workflow modules are the workflow modules you need to trigger and terminate a subroutine workflow.
These modules should be used together – the Subroutine workflow module is the module you insert into the ‘parent’ workflow that initiates the subroutine workflow to start running, while the Return workflow module tells the system to loop back to the parent workflow that triggered it to start running.
Subroutine workflow module
The Subroutine workflow module is available for all event or schedule workflow types. When you want a subroutine workflow to run during a workflow, add the subroutine workflow module to the workflow and configure it with the published subroutine workflow you want to run.
The Subroutine workflow module is available in both event and scheduled workflow types.
Once you’ve configured the workflow module, the Return workflow module will automatically populate onto the editor. This isn’t a termination point for events and scheduled workflows. So, link this module to the next workflow module to tell the workflow session how to proceed after the subroutine workflow is completed.
Return workflow module
This workflow module is only available on all workflows. This module automatically populates once you’ve configured the Subroutine workflow module for event and scheduled workflows. So, you’ll drag and drop this workflow module onto the editor for subroutine workflows.
This module marks the termination point for the subroutine workflows.
Common use cases
Below are some common use cases for using the Subroutine modules:
Business hours: When you’ve built multiple workflows that need to reuse the same business hours branching experience, create and publish a Business Hours subroutine workflow that runs within each of those workflows.
Collecting payment: When you need several queue team’s to securely collect payment from customers, build and publish an Automated Payment workflow that triggers the Gather Credit Card subroutine workflow within that workflow.
Customer satisfaction: When you want to gauge the customer's sentiment/satisfaction of an interaction for several different teams, build and publish a CSAT subroutine that’s nested inside the post-call workflow for each of your queue teams.
Subroutine workflows let you build and publish once and reuse over and over again. The Subroutine workflow module is the module you use inside the ‘parent’ workflow that tells the workflow to trigger the subroutine workflow that you’ve built, and the Return workflow module is the workflow module that you use inside the subroutine workflow that tells the system to send the subroutine workflow session back to the ‘parent’ workflow that first triggered the subroutine to start.
Visual breakdown
Subroutine module breakdown
This section contains a breakdown of each configurable option in the Subroutine module.
Workflow: The Workflow dropdown allows you to select the published subroutine workflow. The published subroutine workflow that you select is the subroutine that’s triggered to run when the workflow session reaches this branch of the workflow.
Workflow Version: The Workflow Version dropdown allows you to define which version of that published subroutine you want triggered. The drop down shows all published versions of the subroutine. So, if there’s any unpublished versions of the subroutine created for the workflow, they won’t populate in this dropdown.
Pop Out (A): The Pop Out button (box with arrow icon) allows you to open the subroutine workflow version once it’s selected. The pop out feature is useful to easily open the subroutine to look it over.
Return workflow module
The Return module doesn’t have any configurable fields because it always executes one automation. It returns the subroutine back to the ‘parent’ workflow that triggered it.
