What could cause a custom fallback intent to not be triggered?

1
votes

I have made a custom fallback intent with an input context "Con-Ser-Klacht-channelKeuzeInput". But when I test my agent, the default fallback intent is triggered even though "Con-Ser-Klacht-channelKeuzeInput" is active.

I thought that more specific intents (i.e. more input contexts) have priority over less specific ones. So what could cause this behaviour?

I have already checked for typos, but the active context is identical to the input context of the custom fallback.

Here are the relevant intents:

2.2.16.02.05-X-Con-Ser-Klacht-Input
input contexts: Con-Ser-Klacht-channelKeuze, Con-Ser-Klacht-Input
output contexts: (3) Con-Ser-Klacht-channelKeuze, (3) Con-Ser-Klacht-channelKeuzeInput, (0) Con-Ser-Klacht-Input 



2.2.16.02.04-X-Con-Ser-Klacht-Fallback
input contexts: Con-Ser-Klacht-channelKeuzeInput
output contexts: (3) Con-Ser-Klacht-channelKeuze, (3) Con-Ser-Klacht-channelKeuzeInput , (3) Con-Ser-Klacht-Input

Screenshot of DF Console

1
dialogflow-esfallback
It should if all the input contexts are active, so this sounds odd. Is this happening when you're testing it using the console, or are you testing this from your own calls. Can you update the question to include screen shots showing what is going on and the code you're using to make the calls if that's how you're trying to trigger intents? – Prisoner
I'm testing in the console. – Renate van der Bent
Can you update the question to include screen shots from the console? They can often provide information that helps in diagnosing the problem. – Prisoner
I added a screen shot. I also put the actual names instead of the placeholder names (I initially used placholder intent and context names because the real ones are long and in Dutch) – Renate van der Bent

1 Answers

1
votes

I figured it out. The default fallback also had an input context that was active (gl-consument). Since both fallbacks had just one input context, the custom one did not have priority over the default one.