Get Started with Call Flow Design

Introduction

One of the most critical aspects of a CPaaS deployment is determining how to programmatically control live calls. In other words, how to design your Call Flows. Complexity increases with the number of possible actions that can be taken on a call and the variety of call flows your application needs to support. Keeping with Voxology’s philosophy of shifting complexity away from customer applications to our platform, our Control Flow Actions for Programmable Voice, when used effectively, can prevent your application from tracking the current state of every live call.

Dealing With Complexity

How It Works

Voxology’s Programmable Voice includes control flow actions that allow you to create call flows with ease.

Control Flow Actions

Voxology has multiple Call Flow Actions that enable conditional logic in the call flow itself. This allows the developer to determine the next action to be taken on a live call, based on actions already performed on the call, without any input from their application.

The Control Flow Actions available to Voxology users are:

IF // Basic if-then-else conditional
FOREACH // iterate through an array or object to perform an action multiple times
LABEL // Label a section of your Call Flow for segmentation
GOTO // Jump to specific LABEL in your Call Flow

Before we go through an example of how these are used, let’s review how a developer might build an IVR without Control Flow Actions.

The Hard Way

Build an IVR without control flow actions

Consider the example IVR tree shown in the diagram here. In this example, the user would call in and hear an initial IVR prompt with 3 options (Menu 1). Depending on which option was selected, there would be one of 3 possible menus played next (Menu 2a/b/c), each with their own 3 options and a corresponding action to be taken (Actions A-I).

To achieve this without Control Flow actions, a developer would need to break this IVR into many parts. One part for each of the menus and then one part for the corresponding actions the call would take based on the caller’s final selection.

Here is the same IVR tree, broken into segments according to how a developer’s application would need to serve the many Call Flow parts.

This is when it starts to get complicated. Looking at Menu 1 and Menus 2a, 2b and 2c, each of these IVR menus have the same options: Press 1, Press 2 and Press 3. However, the actions your application would serve are very different based on where the caller is in the IVR tree. For each digit pressed, the application needs to maintain state. It needs to know, not only which digit was pressed, but which prompt the digit was pressed in response to.

The following diagram shows the interactions required between Voxology and the developer’s application to support this kind of IVR design.

Developer Keeps Track Of State

Imagine your application has to handle multiple IVRs, each with their own series of menus, sub menus and actions to be taken. You can see how this quickly becomes quite complicated for any application to make sense of. This is affectionately known as “callback hell” - dealing with nested callbacks, and it gets even worse when you add error handling into the mix. As you scale to large volumes, the load on your application can grow exponentially from tracking the state of many calls across many IVRs in order to know which Call Flow actions to serve to each call.

Thankfully, there is a better way. You don’t have to build a multithreaded state machine to support an IVR. Let’s review how Voxology’s Control Flow Actions simplify this design.

The Easy Way

Build an IVR with Control Flow Actions

For this example, we’ll consider the same IVR decision tree shown above, but this time utilizing Control Flow Actions.

Again, the Control Flow Actions available to Voxology users are:

IF // Basic if-then-else conditional
FOREACH // iterate through an array or object to perform an action multiple times
LABEL // Label a section of your Call Flow for segmentation
GOTO // Jump to specific LABEL in your Call Flow

For the purposes of this example, we’ll use the IF, LABEL and GOTO Actions.

To begin the IVR journey, we’ll start with a COLLECT action to prompt the caller to make their first by pressing 1, 2, or 3 on their dial pad. Directly after the COLLECT action we’ll place multiple IF actions to tell the Call Flow what to do based on the digit pressed. Within the IF action, we’ll use the GOTO action, with a corresponding LABEL, to jump to the appropriate section of the Call Flow.

Example Request // Make Call

 {
       "type": "COLLECT",
       "params": {
           "num_digits": 1,
           "timeout": 10000,
           "input": "key_presses"
       },
       "actions": [
           {
               "type": "SAY",
               "params": {
                   "text": "Press 1 for account information. Press 2 to make a payment on your account. Press 3 to schedule an appointment."
               }
           }
       ]
     },
     {
       "type": "IF",
       "condition": "$keyPresses == '1'",
       "then": [
           {
               "type":"GOTO",
               "label":"account__menu"
           }
       ]
     },

By using the Control Flow Actions, a Voxology user is able to reduce the number of callback requests required to run the call to a single callback response. Further, because no interaction with your application is required to determine the next steps in the Call Flow, you can host your Call Flow script in a CDN, such as AWS S3 or Google Cloud Storage, and eliminate the load put on your application altogether.

Compare the previous interaction diagram to this new one. Both cases support the same IVR tree, but this one is much simpler.

Voxology Keeps Track Of State

The best part of using the Control Flow Actions is they enable you to support complex use cases without putting additional load on your application. Consider if the IVR tree we were building had more than two layers. Each additional layer in the IVR would require one more interaction with your application to determine the next step based not only on the last action taken, but all actions taken previously as well. With Control Flow Actions, you can program a nearly endless amount of decisions into the Call Flow and continue to run off a single Callback Request to a CDN.

Conclusion

As you can see, the complexity of your Programmable Voice deployment can vary widely. By using only basic call controls and relying on your application to track the state of live calls, users run the risk of needing to account for what feels like infinite complexity. Voxology’s Control Flow Actions effectively allow you to shift that complexity to our platform.

Getting Started

Get started with Voxology's Programmable Voice: https://voxolo.gy/services/programmable-voice