How to test your IVR and call flows with live logging

The safest way to test call flows and find out exactly what is happening at each stage is to examine the Live logswhilst making test calls. You find it here:

Reporting > Live logs

This is essentially a readout of almost everything that happens when a call comes in on a call.

Here we'll be testing a very simple flow in order to check whether certain things are happening correctly during the call. Often it is unclear whether they have happened just by listening to the call, so the logs provide a quick reference for all call activities.

The call will be routed straight to an Input Reader where a DTMF input variable will be stored: "1" for support, "2" for sales.

Then the call will be routed to a Switch Node, which will use the variable value to decide which module to route the call to – either 'Sales info' (pressed 1) or 'Support info' (pressed 2).

Now let's make a test call. In order to route the call straight to the Input Reader we need to go to 'My Settings' > 'Numbers', find the number which you would like to test with and select the Input Reader application. 

Then, we call that number. Make sure to have the Logs open in another tab or window so you can see them appear in real time. 

This is the Logs readout from that call. Note the timestamps recorded for each log entry:

When the number was called, a list of options was played, asking the caller to press 1 for sales information or 2 for support information. "2" was entered at this point. But after "2" was processed as a DTMF input, the call was routed to support information, not sales. Let's take another look at the Logs to see what could have gone wrong:

As you can see, a bit of detective work is required to see what happened when. We can break the call logs down into 3 parts with the help of the timestamps:

1. The first part happens at 10:01:27 – the inbound call attempt appears, and the audio of the module lists the options (press 1 for support, 2 for sales). 
   
   
2. Moving up to step 2 (10:01:33 - info & trace):
   
   "2" was pressed during the call, and we can see a highlighted log in this part: "read input answer= [2]". "serviceoption" was the input variable, so the DTMF input "2" was stored successfully as this variable.
   
   
3. Part three happens in the same second as part two, but we can see that everything in this part happens in the 'Service options switch' application (the first row in the screenshot). After having reached this app successfully, we see that one of the log entries begins with "[switchNode]". This indicates that this log entry will give information about what happened when the Switch Node decided where to route the call.
   
   The triggered app is [Support info and call flow] and shows which module the call went to, but below this we can see that the Trigger] "Caller chooses sales" was fired. Here is our problem: the routing options in the Switch Node are mixed up. 

In order to fix this, we just have to go back to the 'Applications' view, enter the settings for 'Service options switch' and make sure that the routing to the sales and support information application modules matches up with their respective triggers. Et voilà! The next call gave the correct routing and produced these logs: