ambitious-aqua•16mo ago
interact with intent is not working as intended
Instead of going to the booking_confirmation, the response are just traces from the flow the user was before.
What am I missing?

27 Replies
ambitious-aquaOP•16mo ago
Solved when added the "confidence" attribute to action.payload, apparently it's required even tho the documentation say it's not?
ambitious-aquaOP•16mo ago
\

ambitious-aquaOP•16mo ago
not totally solved since voiceflow is not returning the expected traces after the intent
https://discord.com/channels/1079548823610871889/1243337496293802004
@NiKo | Voiceflow thoughts?
ambitious-aquaOP•16mo ago
tried to follow @NiKo | Voiceflow solution from 08/2023 but did not work as well
https://discord.com/channels/1079548823610871889/1142202443980087397/1142571459429011486
can anybod help?
It should work without the need of the confidence. Is the intent scope global?
ambitious-aquaOP•16mo ago
as I mentioned here -> https://discord.com/channels/1079548823610871889/1243337496293802004/1243605361357754548
yes, the intent scope is global
It should but it's not working without the Confidence step. It's not working with it also, but it works "better"
without confidence, the response traces are totally unrelated to the intent I sent the user to. It makes no sense to me.
ambitious-aquaOP•16mo ago
WITHOUT CONFIDENCE ATTR:

ambitious-aquaOP•16mo ago
on the other hand, with the confidence level, the first logs acknowledges the intent_resolved:
Without confidence, it does not happen, as you can see on the image above.
PS: it's not working FULLY with the confidence, since after recognizing the intent_resolved, the next traces are totally unrelated to the booking_confirmation intent action
I've spent hours trying to solve this. Unfortunately the documentation is not totally up to date, and the past discord conversations are not helping either.
After searching for related threads, I tried the only thread about this I could find (from @NiKo | Voiceflow) -> https://discord.com/channels/1079548823610871889/1142202443980087397/1142571038199263295
(it did not work)
ambitious-aquaOP•16mo ago
WITH CONFIDENCE:

ambitious-aquaOP•16mo ago
Would love to get some help, we've been using voiceflow for 6+ months and never had a problem like this.
Is there any chance it only works if the user is currently in a capture step?
Since Im using this to confirm medical appointments 24 hours before, I need to be able to move the user to the booking_confirmation intent despite where he is currently on the flow
Maybe the update state is more adequate in this scenario? However I hope not since I don't want to rely on manually hardcoding (node) ids on the requests
After further testing we concluded that, in order for the INTERACT INTENT to work, the agent has to be listening for an intent. Otherwise, it does not work.
This poses a new issue since like I stated, I need to change the user to the confirmation intent no matter where he currently is.
What do you guys suggest me?
a) make all my capture steps listen for intent (will probably make this particualr issue go away, but is very prone to introducing new ones)
b) use update state API instead. the downside being that I must hardcode the IDs, and since Im expecting this (change state manually) to be a core mechanic of our next version, I'm afraid relying on many hardcoded field my be bad.
c) open to ideas :)
Not sure I get it right, I've just tested with an Intent linked to a workflow and it works as expected, no need to send confidence value or being in a listening state.

genetic-orange•16mo ago
in what step was this interact intent run on?
ambitious-aquaOP•16mo ago
@shen works with me and will handle from now on
genetic-orange•16mo ago
@NiKo | Voiceflow is there a way to FORCE an intent change? not based on an answer like the capture or choice steps;
the "Interact Intent" endpoint only forces the change when the assistant is LISTENING for an intent. can i "update" their state somehow to displace them in the flow?
ambitious-aquaOP•16mo ago
In other words, we need to make interact intent work even if the user is not currently on a step that listens for intents.
We can't predict in which node the user will be. And editing all our steps to listen for intents posed several new errors
Is there a way to achieve this? Or should we resort to update state?
can you help @SuperZooper?
harsh-harlequin•16mo ago
we got the same concern,
if any update, we'll be happy to know
meanwhile we are working on it as well
if we got any interesting news, we'll let u know
hey guys
rather than Intent, what about launch request ?
ambitious-aquaOP•16mo ago
@Reach Launch just starts the conversation, meanwhile Intent should move the user to the intent flow. They serve different purposes
our current knowledge of the matter is that
1) INTERACT_INTENT won't work unless the user is already on a step that listens for intents.
2) MAYBE update_state should work for forcing the state change, however hardcoding nodeID's it not a good practice
Is there anyone that could confirm this for us please?
This is really frustrating.
Thesis: INTERACT INTENT won't work if user is on capture/listen step without global intent scoping.
We'll run another battery of tests and report back
Just to be sure we are on the same page, what kind of integration are you doing?
Are you using the Chat Widget or are you making those request from a custom integration?
If you're using the Chat Widget, how are you making the request using the interact API from the chat widget?
I was testing direct calls to the DM API and I was able to trigger any intents linked to a workflow without any issue or the need to be in a listen state on my end.
ambitious-aquaOP•16mo ago
1) custom integration
2) our specific use case is: we need to force a jump to the intent even if the user is in a step with local scope
when the scope of the capture is local, instead of jumping it generates a random input to the capture and continues the flow:
ambitious-aquaOP•16mo ago
1. user was on a capture step (get name), with local scope
2. we sent an interact-intent
3. instead of jumping, it responded to the "get name" and mistakenly continued the flow

ambitious-aquaOP•16mo ago
Changing the scope of the capture to global fixes this;
however changing all our captures to global introduces new problems.
Thanks for the context, I'm able to repro now. As the Capture step intent scoping is local there's now way to trigger another intent. I'm testing deeper to see if I can find a workaround.
If you're using the capture step to capture entire user reply then you can switch to a Choice step populated with one or more "trigger" intents linked to their corresponding subflow.
Add a No Match path to the Choice step and set intent scoping to local.
That way you can get entire user reply (no match path) or trigger one of the available intents in that step.
Here is a quick loom on how to do this within a limited scope using a Choice step:
https://www.loom.com/share/714de6fcfeee456ebdea62ebdaac5127?sid=ce97b95d-f5f5-46bc-bfab-63205decbad6
ambitious-aquaOP•16mo ago
Thank you for your help and attention.
Unfortunately, this solution is not feasible for our case, because:
The user should only access the intent booking_confirmations externally/forcibly (via API, 24 hrs before the appointment)
If I put it the intents on every LISTEN, there's a very high chance of throwing the user into booking_confirmation because of something they answered, which we can't let happen. (since this specfic intent should only be externally acessible)
@shen suggested removing the utterance from the bookign_confirmation intent, which I believe would eliminate the previous problem of accidentally throwing the user to intent.
However, some of our external-intents should also be available internally, meaning that some intents need utterances.
Do you see a workaround for this? For being able to move the user irregardless of where he is, but without the danger of accidentaly moving people because of what they said in the capture step? (since now its listening for intents when in reality it should not, it should listen only if the intent came from interact_intent)
If not, here are 2 suggestions we've thought of so far:
1 - if there is a way to solve this via update-state, to force the change of state, perhaps it would be a simpler solution, even though hardcoding ID's is not a good practice. however, we have not been able to make it work.
2 - have some kind of attribute in the interact-intent like “force”, and if it's TRUE, it jumps the user to the target intent regardless of whether he's in a block with local or global scope
We are going to migrate the Intent step to a "Triggers" step and this will remove the need of using Intents for events.
https://changelog.voiceflow.com/en/upcoming-release-migration-from-intent-step-to-triggers-step?user_id=1d3d1865-7159-498e-a23d-50802abd325a
Upcoming Release: Migration from Intent step to Triggers step - Voiceflow
Upcoming Release: Migration from Intent step to Triggers step - Voi...
Introducing the new Trigger stepIn our ongoing efforts to enhance the scalability and flexibility of your agents on Voiceflow, we’re excited to announce a significant update coming in June: the transition from Intent steps to Trigger steps. Key ChangesIntroduction of Trigger steps:We are introducing a new type of step called Triggers. This new s...
ambitious-aquaOP•16mo ago
This seems great, I hope it address the issue we're talking about. We'll be able to forcefully move the user then? (despite of current-step-scope)
Meanwhile, do you think it's possible to solve my issue using UpdateState API?