Hi,
our instance is running on USW2 (btw, on the forum there is no option for that while registering, only us-east-1)
I am trying to set up my web site with the v1.1 of the widgets but it seems the reference to the api (api.mypurecloud.com becomes api.usw2.pure.cloud for us) is coming from somewhere behind cloudfront. I have set up the script
<script
id="purecloud-webchat-js"
type="text/javascript"
src="https two points slash slash apps.usw2.pure.cloud slash webchat slash jsapi-v1.js"
region="us-west-2"
org-guid="myid"
deployment-key="mykey"
but still when the query to webchat/guest/conversations is sent, it goes to
https colon slash slash api.mypurecloud.com slash api slash v2 slash webchat slash guest slash conversations
I need it to go to api.usw2.pure.cloud/api/v2/webchat/guest/conversations
I am basically using the sample provided in the
webchat page of the developer center
I was able to get it to work using w2, but it goes staight to a queue and I need it to go to a flow which it seems is not supported by v2 yet.
Is there something else to modify for webchat widget v1.1 to be supported in USW2?
thank you
BTW, this 2 links thing is silly
With the new Widgets - version (2) [the client interface exposed to the customer for Chat], it is possible to trigger an Architect flow (instead of a Queue).
The flow to trigger is not specified in the client configuration (the widgets client) but is configured at the Widget deployment level.
In the PureCloud UI, Admin - Contact Center - Widgets, create a Widget (a.k.a. Widget Deployment), select Widget Type - Version 2, and specify the flow you want to trigger at the bottom of the page in Route to Flow drop-down.
Developer Tools link for USW2 & URLs for the widgets
Thank you Jerome,
I was able to get things to work for v1.1 and start executing my flow (now to troubleshoot the integration to salesforce and lex, but that's another story). What was missing was realtime.usw2.pure.cloud I guess the correct orgid helps too
The developers tool are super useful, thank you.
For v2, I'm still a bit confused by the fact that this seems to be mandatory
interactionData: {
routing: {
targetType: 'QUEUE',
targetAddress: 'Queue_Service'
}
But I added some "SendResponse" at the top of my flow and it seems I need to look at what is happening inside "Find Legacy queue", I can dive into that.
Regarding interactionData, I think that you can put what you want in the targetAddress now (I mean I don't think it has to be a real/existing queue name). It was mandatory to have something valid when routing through Architect flow was not yet supported.
As you mention the Find Legacy Queue (in the base Chat flow in Architect), this is for customers who wanted to move to a flow, but who wanted to keep using the queue name (coming from the client side/widget configuration).
You can safely delete that part in the base Chat flow if you are not planning to use that legacy queue name coming from the widget client. There is a notification mentioning this when you create a new chat flow:
"When you create a new Inbound Chat Flow, Architect adds a task and actions with default logic to honor legacy queue routing for chats. You may safely remove the task and actions if legacy queue routing is not needed in the flow, or edit the default logic as needed."
That's what I do with my chat flows. I remove all of this logic (all the blocks) and connect mines (the new logic) directly to the start block.
Hi Jerome, So I'm not sure I understand the concept of legacy queue. My callflow has a lex box, but some of the intents are about transfering to an agent. So once I transfer to an agent, I want the subsequents interactions to continue this discussion, even if it is a different agent, at least during the life of a session (25h I think?)
Is this used for this purpose or is it something completely different?
I haven't used Lex so far/yet. But it shouldn't matter for my answer
One thing to understand is that the PureCloud WebChat is session based.
When you initiate a chat, it will create a chat conversation (session).
So while your customer is exchanging messages with Lex, via PureCloud, it is part of a single session.
When you request to transfer to an agent, it is still the same webchat session.
messages will be exchanged within that session. So you only transfer to an agent once, from the Architect flow. The Architect flow is then stopped. Agent will be able to exchange messages with the customer.
The agent can transfer to another agent, to a queue, or terminate the chat session.
One timer/timeout to take into account is that if the customer doesn't send any messages for 15 mn (I think it is 15 mn), the chat session will be closed.
The customer can start a new session, but it will then kick the Architect flow again (new session/new conversation).
If the customer starts a new session, when it gets transferred to an agent (transfer to agent again in the Architect flow), the agent will have a view on past interactions with this same customer and he can consult the past chat transcripts.
Thank you, great information. I removed the legacy queue part of the flow.
Last question, is that 15 minutes configurable in any way? although for a web chat it's probably fine. It is for messaging that I would want something longer but I haven't dived into that yet
The 15 minutes is not configurable. But it only applies while interacting with an agent.
There is a note on this page: https://developer.mypurecloud.com/api/webchat/guestchat.html#send_typing_indicator
"While connected to an agent, if the guest does not send any messages for 15 minutes, the guest will be automatically disconnected. This timeout only applies while connected to an agent; activity is not required from the guest while waiting in queue."
This is for WebChat. Message/Messaging works differently.
If ever that can be a problem for you (with WebChat), then I would suggest to use Widgets Version 2. These Widgets also expose an API (commands and events), that can be leveraged via javascript on the web client side.
It is possible to subscribe to events (like a notification of a received message, a user/agent joining the chat, ...) and to send commands (like sending a chat message via code). So you could start a timer when the chat is started (or upon last message sent by the customer) and periodically send a message (acting as a sort of keep-alive).
There are explanations on widgets in different web sites. But this one is probably the one with the more information: https://docs.genesys.com/Documentation/GWC/Current/WidgetsAPI/Welcome
It is the documentation for our PureEngage platform. But the widgets (WebChat/WebChatService) are compatible with Genesys Cloud, PureEngage and PureConnect (just a difference in configuration for the options related to url/transport).
