Guest Chat API chat interaction to Inbound Chat Flows?

[wchavez]

Good morning, forum:

In advance, I appreciate your help in clarifying the following question:
When we use the Guest Chat API to generate chat interactions that would be routed in PureCloud, could we specify an inbound chat flow instead of a queue? If it is possible, how should be defined the following JSON properties in the Guest Chat API request?

"routingTarget" : {
"targetType" : "?",
"targetAddress": "?"
}

Or how should it be declared?

If it is not possible nowadays, it would be included in the roadmap? or, would you please recommend to us other way to do that?

References:

1. https://developer.mypurecloud.com/api/webchat/guestchat.html
2. https://developer.mypurecloud.com/forum/t/new-feature-guest-and-agent-chat-apis/5237

Thank you.

[Jerome.Saint-Marc]

Hello,

deploymentId (in Guest Chat API) is what allows to target a specific Architect Chat Flow, given that you have defined a Widget Deployment upfront (PureCloud Admin - Contact Center - Widgets), pointing to that Architect Chat flow (in the "Route to Flow" setting), and that you use the corresponding deploymentKey in your new chat request as deploymentId.

Please see here for similar question/answer: https://developer.mypurecloud.com/forum/t/3rd-party-chatbot-using-inbound-chat-flow/8527/7

Regards,

[wchavez]

Thank you very much Jerome for your help.

[Jerome.Saint-Marc]

You're welcome.

As a note, I think (almost sure but I haven't tried/tested this for a while) that you still need to set your routingTarget structure in the Create Chat request, even if you target an Architect Chat Flow (via the deploymentId).
targetType will still be set to QUEUE.
You can put the value you want in targetAddress (valid Queue name or not).
You will be able to retrieve that targetAddress (Queue name) in the conversation's participant data/attributes - in context.genesys.legacyRoutingTargetQueueAddress
(in case you also want to leverage that info/value in your Architect flow - as a fallback or else).

[wchavez]

Yes, I was going to ask you that.
Thank you for explain to me those details.
I am going to test it.

[wchavez]

@Jerome.Saint-Marc

As a note, I think (almost sure but I haven't tried/tested this for a while) that you still need to set your routingTarget structure in the Create Chat request, even if you target an Architect Chat Flow (via the deploymentId).
targetType will still be set to QUEUE.
You can put the value you want in targetAddress (valid Queue name or not).
You will be able to retrieve that targetAddress (Queue name) in the conversation's participant data/attributes - in context.genesys.legacyRoutingTargetQueueAddress
(in case you also want to leverage that info/value in your Architect flow - as a fallback or else).

Thank you Jerome. I tested and it worked for me.

Also, in Architect Inbound Chat Flow you have the "Call "Find Legacy Queue" task" and a "Legacy queue found?" decision that, I understood, enable us to select a default queue, if the queueName specified in the routingTarget object could not be found.

Thank you, again, for your clarifications and instructions.

[Jerome.Saint-Marc]

The Find Legacy was put there, so some customers could continue to leverage the Queue defined in the create chat request (on customer side - I mean widgets side).
So more like a sample to help them have a working flow (if they use Queue - but still enable the routing through Architect).

Personally (but I am not creating Architect Chat flows for Production), when I create a new chat flow, I just delete all the blocks and this Find Legacy Queue task. And "start" with an empty Chat flow (as I am not relying on the queue sent from widgets).

So I guess that yes, the Legacy queue found decision is there to manage the case where you would enter an unexisting queue name in create chat request, and try to use something default in this case. The Queue name needs to be resolved in an object of Queue type to be used in a target object.

Hope that clarifies.

[wchavez]

I understood Jerome, thank you.