Overview: Subroutine workflows (Console)

This article explains the subroutine and secure subroutine workflows feature in Console.

In this article

Overview

In Workflows, you can create a few different types of workflows: event workflows, scheduled workflows, or subroutine workflows. A subroutine workflow is a workflow that runs within another workflow. It’s common to refer to the subroutine as the child workflow and the workflow that runs the subroutine as the parent workflow. 

There are two types of subroutines that you can create: a secure subroutine or a subroutine. Refer to the Secure subroutines section of this article to learn more about secure subroutine.

Here’s how a subroutine works. When a workflow includes a Subroutine module, it sends a message to the linked subroutine workflow telling it to run. When the subroutine finishes running, it sends a response (and any included data) back to the parent.

Some things to know about subroutine workflows:

• You can create a subroutine with any workflow category. 

• There’s no limit to the number of subroutines that you can create and you can use a subroutine with an unlimited number of parent workflows.

It’s important to keep in mind that subroutines can’t run other subroutines, nor can they: 

• Create interactions

• Transfer interactions

• Terminate with an “end” module (instead, they terminate with a “return” module that links it back to the parent)

• Convert to being a parent workflow; once a workflow is created as a subroutine, it’s always a subroutine workflow

Why use subroutines?

Subroutines are most useful when you want to use the same workflow modules across multiple workflows. Let’s consider a common use case:

Suppose that your business has multiple inbound workflows that route callers to various departments. You want your workflows to check whether the business is open. One way of doing this would be to use the Time Control module across every workflow on your account to check whether the business is open and route the caller accordingly.

It’d be a pain, though, if the hours of your business ever changed. You would have to find each workflow created on your account using the Time Control module and make sure to update it to the new time.

Subroutines take the pain out of the equation by allowing you to create one workflow that checks business hours and then linking it to an unlimited number of other workflows. This means that all of your workflows could reference one subroutine to check business hours. And, if your business hours ever change, you only have the one workflow to modify. 

This is just one example of how the subroutine module could simplify your workflows and make your job easier.

Take a closer look at subroutines

Parent workflow

Figure C

In the screenshot above (Figure C), we’re zoomed into our inbound workflow featuring a subroutine. If you double-click a subroutine, you’ll see the Workflow and Workflow Version selectors in the right sidebar. This is where you select what workflow you want to run. 

Note: Only workflows created with the type “Subroutine” will appear in the selectors on the Subroutine module.

Once you’ve selected the workflow you want to run as a subroutine, the Return module will automatically populate onto the workflow editor. This is where the subroutine will return its resulting data (if any).

When you drag-and-drop a subroutine module onto the workflow editor, it automatically produces a linked module called If Error. This module is the route the workflow takes if the subroutine fails for some reason. For example, for secure subroutines, if a customer’s SMS reaches the Subroutine module, then it will be routed to the If Error module because secure subroutines only handle phone calls. So, it’s a good idea to make sure there’s a fallback option in case a subroutine were to fail.

In our scenario, if the subroutine fails, the caller is routed to the general queue, where they’ll either be connected to an agent or given the chance to leave a voicemail on the queue.

The next step to understanding subroutines is to take a closer look at the subroutine workflow itself.

Child (subroutine) workflow

Figure D

In the screenshot above (Figure D), we can see a fairly simple workflow that’s using the Time Controls module to check business hours. 

• If the business hours are met (if the business is open), then it routes to a Set Variable module declaring a variable as true.

• Conversely, if the business hours are not met (if the business is closed), then it routes to a different Set Variable declaring a variable as false.

So, what does this mean? This means that the subroutine is checking to see whether the business is open. Depending on the result, it’s declaring a variable. We then see that it links to a Return module, which ends the subroutine.

Where does the variable go once it’s declared? The key is the Return link between the subroutine and the parent workflow. Once the session reaches the Return module, the subroutine’s workflow session data is sent to the parent workflow and it’s used to determine how to direct the workflow session next.

Return to the parent workflow

Let’s now take a look at the parent workflow again. 

We’re looking at the parent workflow again in the screenshot above (Figure E). The highlighted Return module is the link between the subroutine and the parent workflow. Any variables declared in the subroutine (so long as the subroutine isn’t marked as Secure) are transferred back to the parent workflow.

We can then use the Decision module to evaluate the variable declared in the subroutine, in this case the variable being ifTimeControlMet. 

The Decision module depicted above (Figure F) is set up to evaluate the variable timeControlMet, which is the data collected and transferred from the subroutine workflow. Remember from the section above that this variable would only be true if the Time Control module determined the business was open. So, it being true means that the business is open.

From the Decision module, we can then route down two different branches: 

• One where the business is open, using a Say + Intent module to determine which queue to route the caller to.

• One where the business is closed, using a Create Interaction module to give the caller an opportunity to leave a voicemail message.

How do I check if a workflow is a subroutine?

When browsing workflows, you can quickly tell at a glance if a workflow is a subroutine by the Type column from the Workflows list workspace.

Secure subroutines

A secure subroutine workflow is a subroutine workflow that specializes in processing data in an environment with extra layers of security to align with the type of data these types of workflows handle. 

All workflows are secure; but when marking a subroutine as “Secure”, you’re defining that this particular subroutine requires an additional layer of security - or additional data limitation - so these types of subroutines remove certain features available in other typical workflows. 

All logic performed within the secure subroutine takes place in an environment with additional security layers, like limiting how data is transferred between workflows, etc. That means that all data collected or produced in the subroutine remains in the subroutine. 

In other words, it doesn’t automatically transfer back to the parent workflow, which is common for all other workflow types to take advantage of using that data to make workflow decisions. 

• Phone calls only: Secure subroutines only work for phone calls.
  
  

• Phone calls must be active: Secure subroutines only work when there is an active phone call. If a call is disconnected while the subroutine is running, the subroutine will automatically fail and route down the Error path.
  
  

• No audio inputs collected: Secure subroutines only gather DTMF inputs - no audio inputs are gathered. So, secure subroutines can’t make use of any audio inputs from Say + Intent or Say + Gather modules. Instead, DTMF responses can be utilized to gather customer input.
  
  

• Some modules not included: Secure subroutines have fewer workflow modules available.
  
  

• Available for all workflow categories: You can make a secure subroutine for any workflow category.
  
  

• Once secure’, always ‘secure’: Once you create a subroutine to be a secure subroutine, you can’t change it. The subroutine is always set to ‘secure’. This also means that you can’t convert a subroutine to be a secure subroutine. Subroutines need to be created as a secure subroutine from the beginning.

How do I check if a subroutine is secure?

You can check if a subroutine is secure by doing the following:

1. Select any subroutine workflow.

2. Once viewing the workflow, click the tri-dot menu in the top-right corner of the screen.

3. Click Settings.

Figure H

When viewing a workflow, you can see the category, type, and its secure status in the Settings menu.

Creating a subroutine workflow

Creating a subroutine workflow is virtually identical to creating any type of workflow. You just need to remember to set the workflow type as “subroutine”, or else it won’t be able to be used as a subroutine.

Figure I
When creating a subroutine workflow, always remember to set the Type as Subroutine.

Creating a secure subroutine

To create a secure subroutine, click the Secure toggle when creating a subroutine. Note that it’s not possible to change a subroutine to Secure or vice versa after creation. So, once a subroutine is set to ‘Secure’, that subroutine will always be a secure subroutine. It’s also not possible to convert a regular subroutine into a secure subroutine and vice versa.

1. When creating a workflow, set the Type to “Subroutine.”

2. The Secure toggle will appear. Toggle it so that it appears green (toggled on).

3. Click the Save button.

Figure J
When creating a subroutine workflow, use the Secure toggle to make it secure.

Read more

• Overview: Workflows (Console)

• Overview: Workflow workspaces (Console)

• Workflow modules

• Create a workflow (Console)

• Rename a workflow (Console)

• Make a workflow version the current version (Console)