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 logs while making test calls. You find it here:

Monitoring > 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. "1" was entered at this point. And after "1" was processed as a DTMF input, the call was routed to support information. You can see that in the logs:

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:58:39 – 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:58:44 - info & trace):
   
   "1" was pressed during the call, and we can see a highlighted log in this part: "read input serviceoption= [1]". "serviceoption" was the input variable, so the DTMF input "1" was stored successfully as this variable.
   
   
3. Then the system reads the input reader variable (serviceoption - [1]) and as the next step it continues the flow to the Service Option Switch.
   
   The triggered app is [Support information and call flow].

During your testing, if you notice any discrepancies or experience a weird routing in your flow, you can always enable the Live Logs and check what happens throughout the entire call.