If you're testing in Try Out and get an incorrect response, the first thing to do is look more closely at the results to see what happened. You may have noticed a set of small icons under the bot output in the Try Out window. These tell you the path the user input took during the transaction. You'll see here which trigger claimed the input, which flow became active, and all the nodes that were visited. In most cases, you will see output nodes there, but you may also see calls to Sub-Flows or a revisit of a flow that was paused while answering a different question. By clicking one of the icons, you can open the associated flow.
In this example, we can mouseover the trigger icon and see which trigger of which flow responded to the input:
We can see right away that a trigger of a different flow than intended took our input, namely a flow about purchasing a coffee mug, as opposed to ordering a cup of coffee.
How you proceed depends on the kind of triggers that are involved in your problem:
The diagram you see here is an overview of how to troubleshoot the issue of a flow not triggering. You start at the left and work your way through. The nodes in the chart lettered from A1 to A5 and B1 to B2 represent subsequent sections of this page where we describe what to do for each of the cases.
In this section, we will fix the issue of a class match requirement that is not responding to a relevant input. Before we begin, we need to know the top intent and the confidence level it had. You can find this information in Try Out in the section Classifications. The top intent will be at the top of the list, followed by other close-by results, if there are any.
For example, we expect the input I want to order a coffee to be recognized by the class ORDER_A_COFFEE in the flow User wants to order a coffee. But in our solution we have a class I_WANT_TO_BUY_A_MUG responding with a 99.56% confidence:
We will need to adjust the training data of the intended and the competing triggers to give us the correct result for the input. The steps below will guide you through the process of fixing your individual problem.
In this set of steps, we know that the classifier is confused about which class to select.
Here, we will show you how to fix the issue of two different triggers with conditional match requirements competing with each other. Usually, these are quite easy to fix, by adjusting either the conditions in question or the trigger ordering. Remember that with triggers with conditional match requirements, Teneo Engine starts the matching process at the top of the trigger ordering and works its way down until it finds a trigger condition that matches the user input. It will select the first trigger that matches, which is not necessarily the best or the intended trigger. As a general rule, more exact triggers should be ranked higher in the ordering and less exact triggers should be ranked lower.
Perhaps the trigger that responded is not strict enough, allowing it to match on inputs it should leave alone. In this case, you should make the condition of the trigger that 'stole' the input more exact to prevent it from taking inputs from the intended trigger, which is placed lower in the ordering.
Have an initial look at the language condition of the flow you wanted to trigger, to see if there are any obvious problems. Does your input match the condition at all? You could add the input that failed as an example to the trigger and run an Auto-test at flow scope to make sure. Maybe you need to broaden the scope of the condition. For example, this condition would not respond to 'I want to order an espresso' because it uses the language object COFFEE.NN.LEX, which contains only the words coffee and coffees:
%I_WANT.PHR &^ %ORDER.VB.SYN &^ %COFFEE.NN.LEX
The best solution here is to adjust the condition by replacing COFFEE.NN.LEX with COFFEES_SERVED.ENTITY, which covers all the relevant coffee types.
Here are the steps that should consider to be a suggestion for both of the cases.
If the flow still doesn't trigger, despite the correct top intent having been selected, there may be an issue with the confidence level. For a class match requirement in a trigger to be met, the confidence with which it was selected by the model must be higher than the minimum threshold set at the solution level. If this is the case, we will need to go through some iterations of the steps below:
The required confidence threshold is defined in Solution Properties, which you can view by navigating to the Solution tab, and then the Properties panel.
We have a good confidence score, above the required level, yet the flow is still not triggering.
If this is the case, you will need to check in Try Out to assure that the additional requirements are met or modifed.
At this point, we have the correct top intent and we know it should have been chosen, but a conditional match requirement has gotten in the way. In this case, you should check the language condition of the competing conditional match requirement and make it stricter and more exact.
If the conditions of the two triggers look good, and there are no context restrictions involved, you will likely be able to solve the issue via ordering. Check the two triggers and find out which trigger ordering group they are stored in. You will have to change their relative ordering to make sure that the intended trigger is evaluated before the trigger that stole its input.
You have a number of options:
If the tested user input matches the trigger condition of the intended flow and the flow that responded is the Safetynet, you have a trigger ordering problem. Apparently, the Safetynet was ranked higher than the intended trigger. The order group holding the Safetynet should be last in the hierarchy.
If you have set up a trigger to recognize a follow-up question, it means it will only respond within a certain conversational context. Usually, it means that a specific flow must have fired just before, or a certain topic must be active in the conversation:
Was this page helpful?