Call Flow Scenarios
This guide will cover the use of custom variables, extra items, checking the URI, setting priority, and accessing external data.
Emergency Manager
This example is for an emergency manager call flow. This would be useful in the event that an organization would like to play an emergency greeting if the office is closed for an emergency reason. This call flow takes advantage of config values and Extra Items to allow a user to enter the call flow after entering a password, review the current emergency mode setting (on or off), turn emergency mode on or off, and set the type of emergency.
A Prompt requesting a password is the first node in the call flow. If authorized, the user can turn emergency mode on and off. If not, the system ends the call.
The Check Config node is used to check the configuration setting, visible on the Master Configuration Settings page to determine the value of isEmergencyModeActive.
Based on the value of the config, the Message node relays to the user if emergency mode is on or off.
A Prompt node is used to allow the user to turn emergency mode on or off.
Once the user selects an option from the Prompt, the appropriate value of isEmergencyModeActive is set using a Set Config node.
At this point, another Message node notifies the user that emergency mode has been turned on or off. If emergency mode has been turned off, the call is now terminated.
In this example, we are going to allow the user to set the type of emergency type. This can then be used to indicate which voice prompt to use for the emergency greeting. This is similar to what was done above to turn emergency mode on and off.
The user is prompted to select an emergency type.
After the user selects the desired option from the Prompt node, the configuration setting EmergencyGreeting is updated with the corresponding voice prompt file name. The user is notified via a message node of the new greeting before the system ends the call.
Check Emergency Mode
This example builds off of the previous example, in which emergency mode was turned on and a greeting was set. In this situation, a Check Config is used to determine the values for isEmergencyModeActive, and the EmergencyGreeting (in that order) that were set to route the caller to the correct next node, and to play necessary greetings.
After the welcome node, a Check Config node is used to check the value of isEmergencyModeActive. If it is false, the system proceeds to the standard call menu.
In this scenario, if the value of isEmergencyModeActive is true, the call goes down an alternate path to another Check Config node, which checks the value of EmergencyType to determine which message to play. For a less complicated call flow, this step and the following steps could be replaced with a generic message stating that the office is closed due to an emergency.
A Message node uses the extra item to play the appropriate emergency message.
Extension Transfer
In this example, the main menu Prompt allows for a five digit number to be input, and then transfers the call to that extension.
Some things to note when using the Transfer node are:
- If the system does not find a match to the extension entered, the call will be dropped
- Once a call is transferred to a valid extension, it is no longer tracked in the system
- If you would prefer that a call only be transferred during business hours, a Check Time node should be used to prior to the prompt for an extension.
This Prompt node allows for any five digit number to be entered by including 5 question marks as one of the optional results that it will accept.
The call is then transferred using the extra item as the destination.
Check Balance
This example demonstrates the use of the External Data Access node. This node can be used to obtain data from a database, HTTP web service, or WCF web service. In this example, we are querying the database for the caller’s balance information.
A Prompt node is used to capture the user's account number and store it in an extra item called accountnumber.
Then, an External Data Access node is used to query the database for the account information.
If there is an error attempting to query the database with the number entered, a message instructs the user to re-enter their account number, and they are sent back to the prompt.
After setting external data type to Database, the connection string to connect to the database can be entered.
Ex: Data Source=sql.student01.internal;Initial Catalog=Test_Main;User ID=student;Password=pass@word1;
In this example, a SQL query can be used to obtain the account balance from the accounts table. In order to properly use the extra item, the query is written first using a valid account number. Upon clicking Assign Return Values, a box appears allowing an extra item name for storing the data retrieved from the query.
SELECT AccountBalance FROM Accounts WHERE AccountNumber='12345678'
After assigning the returned AccountBalance to be saved into the extra item accountbalance, the query is edited, replacing the account number of 12345678 with the extra item variable that has captured the user's input account number in this way: {{accountnumber}}. The Assign Return Values button does not need to be clicked again, and the changes will be saved when the node is saved.
SELECT AccountBalance FROM Accounts WHERE AccountNumber='{{accountnumber}}'
A Message node makes use of the extra item containing the account information when the variable is used in the synthesized text box in this way:
Your account balance is {{accountbalance}}
Check Area Code
The Check URI node allows for checking the different types of numbers or URIs associated with the session. In this example, we will check the caller’s number, and route it based on that information.
A Check URI node checks the caller URI and routes it based on the area code.
In the event that the URI has a 630 area code, the call is routed to an Illinois queue, while a 616 area code will route the call to the Michigan queue. Just before being dropped into the queue, the caller is notified that someone from that area will be with them shortly.
Set Priority
The Set Priority node assigns the incoming call a priority level prior to being placed in the queue. In this example, we are using the Check URI node to look at the number being called by the caller. In the event they called a priority line, we are assigning the caller a higher priority before dropping them into the queue. This could also be accomplished by taking advantage of call flow mappings, which also looks at the Incoming URI, and using a different start node for calls to the priority phone number.
A Check URI node looks at the incoming URI, or the number that was dialed by the caller.
If the number matches the criteria, the call is assigned a higher priority. The default priority on queued calls is 0. The priority takes in any integer, with higher numbers being routed first.