If you're testing in Try out and get a wrong 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 the usual case you will see output nodes there, but you may also see calls to subflows or a revisit of a flow that was paused while answering a different question. By clicking one of the icons you 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 class 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 a flow not triggering issue to find a solution. You start at the left and work your way through. The nodes in the chart lettered from A1 to A4 and B1 to B4 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 trigger 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'll find this information in Response Info in the section Intent Classification. The top intent will be at the top of the list, followed by other close by results, if any.
For example, we expect the input I want to buy a coffee from you to be recognized by the trigger Can I order a coffee? in the flow User wants to order a coffee. But in our solution we have a trigger Can I have a coffee mug? responding with a 99.85% confidence:
We will need to adjust the training data of the intended and the competing class 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.
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 trigger to be allowed to fire, 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:
Note: 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. Open the flow in the flow editor, select the class trigger, open the Examples panel and check whether the trigger has a context restriction in place:
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 syntax trigger has gotten in the way. As a rule, syntax triggers are contained in trigger ordering groups above the class triggers, so they have the first shot at the input. In this case you should check the language condition of the competing syntax trigger and make it stricter, more exact.
Here we show you how to fix an issue of two syntax triggers competing with each other. Usually these are quite easy to fix, either by adjusting the conditions in question, or adjustments to the trigger ordering. Remember that with syntax triggers, Teneo Engine starts the matching process at the top of the trigger ordering and work 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 picking up inputs intended for the trigger that should have fired and that 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 add to the syntax, or 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.
It could be that your trigger condition is fine, but that it is using a context restriction that prevents it from firing for this input. Open the flow in the flow editor, select the syntax trigger, open the Examples panel and check whether the trigger has a context restriction in place:
If this is the case, you may be able to solve the issue by assuring via Try out that the additional requirements are met or adjusted.
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 in which trigger ordering group they are stored. 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:
Note: if the tested user input matches the trigger condition of the intended flow and the flow that responded is the safety net, you have a trigger ordering problem. Apparently the safety net was ranked higher than the intended trigger. The order group holding the safetynet should be the last in the hierarchy.
If you have set up a trigger to recognize a followup 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?