Flow Configurations
Understand how to configure sample templates using flow configuration
While you can always configure your own flows for handling incoming inquiries over digital messaging channels (such as SMS, Live Chat, WhatsApp, Facebook Messenger, Email, etc.) supported by Webex Connect and Cisco Contact Center Enterprise (CCE) in combination, we have provided some representative flows to provide you with a reference on how to configure such flows.
These flows are available for download here.
There are a total of 13 representative flows as listed below:
Flow Name | Description | Additional context |
---|---|---|
SMS Inbound Flow | Used to handle incoming messages from end customers over SMS. This flow includes a welcome message and provides options for customers to escalate to an agent or drop out of a conversation using intent keywords. | This flow needs to be configured separately for each SMS number/Sender ID. |
Email Inbound Flow | Used to handle emails from end customers and escalates the task to CCE to assign an agent. | This flow evaluates for any sensitive data / PCI compliance in the email text or attachments and notifies the sender if any sensitive data is detected. This flow needs to be configured separately for each Email asset. |
Live Chat Inbound Flow | Used to handle incoming messages from end customers over live chat. | This flow needs to be configured separately for each Live Chat asset. This flow evaluates for any sensitive data / PCI compliance in the text messages or attachments from end customers and notifies them, if any sensitive data is detected. |
Live Chat Customer Close | Used to handle live chat sessions that are closed or abandoned by end customers and informs the agent that the chat is closed or abandoned. | This flow needs to be configured separately for each Live Chat asset. This flow also handles chats that are abandoned in CCE queue before an agent gets assigned. |
Live Chat with WebCallback Flow | Similar to Live Chat Inbound Flow, but in addition to regular Live Chat, it checks if the task is queued for a certain threshold (1 min, which is configurable) and then prompts the customer if they'd like to be called back instead. | This flow demonstrates how a Live Chat can be turned into a Web Callback and employs the Agent Request feature of CCE under the hood. If Customer opts to be called back, the existing Live Chat request is cancelled, and a Web Callback request is placed instead. These channels / media types are handled through different queues and as soon as an Agent is found, a call is placed to the Customer's phone number. While all the other flows for Web Callback, can be same as that for other channels, there is some special handling that is required to switch media from chat to Voice. A separate flow for CLOSED_Webhook processing which closes the cancelled Live Chat request, and also handles the Closed webhook notification from Digital Routing service as soon as an Agent gets assigned for the Web Callback, is required which needs to be used in conjunction with this flow. It is named Live Chat with WebCallback Flow. |
WebCallback CLOSED | Used in conjunction with Live_Chat_Inbound_With_Web_Callback_Flow to provide special handling when switching media from Live Chat to Voice. | This flow is triggered when an asynchronous CLOSED Webhook notification is sent from the Digital Routing service when: - The customer stays on and completes the conversation over the Live Chat channel, which may include connecting to an Agent or the task being abandoned while in queue. - The customer opts to cancel the Live Chat channel request, and instead receive a Web Callback. A Closed webhook event will be sent indicating the chat request being cancelled. - When CCE assigns an agent for the Voice / Web Callback request and initiates a call to the customer's phone number. |
Facebook Inbound Flow | Used to handle incoming messages posted on a Facebook Page integrated into Webex Connect, by end customers who employ the Facebook Messenger as a channel for communicating with a business. This flow includes a welcome message and options for customers to escalate to an agent or drop out of a conversation using intent keywords. It also showcases and includes rich media controls like a carousel message and quick reply that one can employ while interacting with a customer over the Messenger channel. | This flow needs to be configured separately for each Messenger asset. The flow evaluates for any sensitive data / PCI compliance in the text messages or attachments from end customers and notifies them, if any sensitive data is detected. |
WhatsApp Inbound Flow | Used to handle incoming messages sent to a WhatsApp Business account (WABA). This flow includes a welcome message and options for customers to escalate to an agent or drop out of a conversation using intent keywords. It also showcases and includes rich media controls like an embedded image message and quick reply that one can employ while interacting with a customer over the WhatsApp channel. | This flow needs to be configured separately for each WhatsApp asset. The flow evaluates for any sensitive data / PCI compliance in the text messages or attachments from end customers and notifies them, if any sensitive data is detected. |
CREATED Flow | Used to send the notification message to the end customer over SMS, live chat, and email media channels when a task is created in CCE. | This flow is triggered when an asynchronous CREATED webhook notification from the Digital Routing service is sent owing to the create task request being accepted by the service. These tasks will be subsequently submitted to the CCE router for queueing and routing. On receipt of the notification from the Digital Routing service, the flow sends the notification message to the end customer over the respective channels of communication. |
QUEUED Flow | Used to send the notification message to the end customer over SMS and live chat when there is an update to the Estimated Wait Time (EWT) for a task. | This flow is triggered because of an asynchronous QUEUED webhook notification from the Digital Routing service when: A task is submitted to CCE for queuing or routing. A notification is sent when there are updates to the Estimated Wait Time (EWT) or updates to the task context variables. This requires the RunExternalScript node to be set up in the CCE scripts. Note: When the Digital Routing service submits tasks to CCE, the first queued task will not have any EWT, or the EWT value will be -1. In this scenario, the flow will not send any message to the end customer. The flow sends messages to end customers only if you've set the call.EstimatedWaitTime and use the RunExternalScript node to notify the Digital Routing service of the EWT. |
ROUTED Flow | Used to add an agent participant to a conversation when Webex Connect receives the Task Routed event from Contact Center Enterprise. This flow sends a message to the end customer over SMS or Live Chat, notifying that an agent is about to be added to the conversation. | This flow is triggered when an asynchronous ROUTED webhook notification is sent from the Digital Routing service after CCE assigns an agent to a task. For the conversation to be loaded on the Agent desktop, the Agent should get added as a participant in Webex Engage, which is what this flow is primarily meant for. |
CLOSED Flow | Used to close a conversation in Webex Engage and send a message to the end customer over SMS or Live Chat, notifying that the conversation has been marked as closed. | This flow is triggered when an asynchronous CLOSED webhook notification is sent from the Digital Routing service after agent closes or ends the task on the Agent desktop or when the task is automatically closed by the system due to queuing / routing failures, after being accepted. |
TRANSFERRED Flow | Used to send a message to the end customer over SMS or Live Chat when a conversation is being transferred to another queue by an Agent or when a RONA (Redirect on No Answer) gets triggered owing to No answer or when Agent logs out from the desktop while still having active tasks. | The flow is triggered when an asynchronous TRANSFERRED webhook notification is sent from the Digital Routing service owing to an Agent or system-initiated transfer. It removes the transferring Agent as a participant of the Conversation in Webex Engage, before reinjecting the task into the Digital Routing service for the next agent to be assigned as part of the transfer, by invoking the “CCE Create Task” node with the same CCE taskID as the task being transferred. If the transfer fails, the flow sends a notification message to the end customer over SMS, Live Chat or Email depending on the channel on which the task was created, stating that the conversation will be closed, and the customer must reinitiate it. |
There are some task context variables that get passed along from Webex Connect while creating a task in CCE that are essential for end to end call flow. The task context can comprise of Call Variables, Expanded Call Context (ECC) variables or Extension Variables:-
- Call Variables - There are up to 10 Call Variables of 40 bytes each, that can carry task context data. They translate to Peripheral Variables 1 to 10 in CCE, and are prefixed with the string "cv_" in the Digital Routing API payloads.
- ECC Variables - ECC variables can be up to 210 bytes each and are identified with a prefix "user" in the API payload. These need to be defined in CCE and added to the "Digital Channel Settings" page in CCE Web Administration tool to ensure task context variables can be sent and retained in Digital Routing Service, and in turn available to Webex Connect via Webhook notifications.
- Extension Variables - Extension variables neither have the the ECC variable nor the Call Variable prefix in their names. These are stored in Digital Routing service along with the task and do not get sent as a Call variable in CCE. They are used to store metadata about the task and are used by the Webex Connect flows to communicate with the end customer on a given channel.
Webex Connect automatically populates the following ECC (Expanded Call Context) and Extension variables while invoking the "CCE Create Task" node:
Channel | Field Name in Create Task node | Underlying ECC/Extension variable populated in Task payload |
---|---|---|
SMS | Conversation Id | user_DR_MediaResourceID |
SMS | Customer Name | user_DR_CustomerName |
Live Chat | Conversation Id | user_DR_MediaResourceID |
Live Chat | Customer Name | user_DR_CustomerName |
Live Chat | Live Chat Thread Id | ChatThreadID |
Conversation Id | user_DR_MediaResourceID | |
Customer Name | user_DR_CustomerName | |
Email Message Id | EmailMessageID | |
Subject | EmailSubject | |
Email CC | EmailCCRecipients | |
Email BCC | EmailBCCRecipients | |
Web Callback | Conversation Id | user_DR_MediaResourceID |
Web Callback | Customer Name | user_DR_CustomerName |
Web Callback | LiveChatUserID | LiveChatUserID |
Web Callback | LiveChatThreadID | LiveChatThreadID |
Web Callback | LiveChatAppID | LiveChatAppID |
Facebook Messenger | Conversation Id | user_DR_MediaResourceID |
Facebook Messenger | Customer Name | user_DR_CustomerName |
Conversation Id | user_DR_MediaResourceID | |
Customer Name | user_DR_CustomerName |
You can use these flows to create flows in your Webex Connect account by using the 'Create Flow -> Upload a Flow' method under Flows Tab within a service. These need to be sent as additional Extension variables as part of the Web Callback request. They contain details of the chat channel, through which customer initiated the callback request. It is useful if messages need to be relayed to end customers, while Web Callback is being processed by CCE, or when the Agent gets assigned.
The ECC variables (the ones prefixed with "user_") need to be defined in CCE, prior to importing the flows and trying out the end-to-end call flow.
Creating Flows
To create a flow using upload a flow option:
- Create a Service (it should be the same as the service that you mapped with Cisco Contact Center Enterprise (CCE) for the Messenger asset) and create a flow by importing the representative flow named FBM Inbound Message.
- Click the service and navigate to Service Dashboard.
- Go to the Flows tab.
- Click Create Flow.
- Provide a name for the flow.
- Select Upload a flow in the Method drop-down.
- Click Choose File to upload the required file.
- Click Create.
Note
When a flow is created using an Upload Flow method, it is mandatory to Save the flow before proceeding further. This is required to ensure that configurations are saved correctly. As a known limitation missing this step can lead to Evaluate node script formatting getting lost.
Configure Flows
- Open the required flow in the flow editor.
- Double click the pre-builtCisco Contact Center Enterprise (CCE)nodes one at a time and provide authorization for the concerned node.
- Keep the Method Name as is.
- Select Add New Authorization in the Node Runtime Authorization drop-down.
a. The Add new authorization pop-up window opens.
b. Provide a name for the authorization that appears in the Node Runtime Authorization drop-down. Click Authorize. The Cisco Webex Contact Center Enterprise login page appears and you need to provide valid credentials to add the authorization. - Refer to the pre-built integration node documentation to configure other fields in the node.
- For SMS flow, click the Start Node and select incoming message as the flow trigger option. This step doesn't apply to other channels.
Repeat this process for all of the pre-built integration nodes within the flow.
Publish your flow once you've made all the changes.
Repeat the above steps for the remaining flows.
Understanding Representative Flows
Here's a high-level overview of the logic configured in each of the representative flows. The flow comprises of Conversation nodes that interact with the Webex Engage platform and the Task nodes that interact with the Digital Routing service in CCE.
SMS Inbound Flow
When an inbound message is received over SMS channel, Webex Connect searches for the conversation in Webex Engage. If the conversation already exists, then the incoming message is appended to the existing conversation, else a new conversation is created. Alternately an existing conversation that was previously closed, can also be reopened. Reopening a conversation has the advantage of retaining interaction history with the customer when the conversation lands on the Agent desktop, including all past interactions. The downside is that a new interaction for a completely different service request may get appended to the same conversation, based on Customer's phone number.
The Search Conversation node can have one of the following outcomes, based on the state of the task:-
- noConversationFound - This would be the case for new customer interactions that have no record of previously engaging with the Contact Center on this Media Channel.
- conversationInQueue - The task is currently in Created (or Queued) state in CCE waiting for an Agent to get assigned.
- conversationActive - The task is in Routed state, and the customer is currently interacting with the Agent in an active session.
- conversationClosed - The task is in Closed state or there is no active conversation in the system. The system does recognize the customer though, based on previous interaction history on this specific media channel using the channel specific identifier, which in the case of SMS is Customer's phone number.
- conversationOnHold - This is currently not applicable for CCE, but is one of the responses that Webex Engage can return for the Search Conversation API.
In the representative flow, a new conversation gets created if an existing conversation is found to be closed. Once a new conversation is created, a welcome message is sent to the end customer followed by a couple of options to choose from, so as to determine what service is being requested. Depending on the customer's input, a task would be created in CCE with the corresponding Script Selector being passed in the Create Task API request. Script Selectors determine which CCE script gets executed for the task, which in turn determines which Skill Groups and Precisions Queues should be targeted for the task. One may pass additional call context data to take appropriate routing decisions or determine task priority in CCE scripts.
Search Conversation, Append Conversation, Create Conversation and Close Conversation nodes are designed for conversation handling in Webex Engage.
The flow also allows for and checks whether a customer wants to end an interaction by searching for the "End Conversation" phrase in the text message. This allows the customer to start a new interaction all over again, starting with the welcome message. If the task was already submitted to CCE, the flow invokes the "CCE End Task" node to close or abandon the task, depending on whether the Agent was already assigned to it.
The flow inherently also checks for PCI compliance in the message sent by end customer and informs the end user if sensitive information has been detected. The sensitive data is automatically masked before it gets appended to the Conversation to be sent to the Agent, or recorded as response during self service.
The SMS Inbound flow ends when a task has been created and the CCE taskId has been updated in the Conversation object in Webex Engage.
The following custom variables are used in the flow:-
- errorTechnicalIssue
- errorSendingMessage
- errorServiceNotAvailable
- automatedResponse
- actual_message_content
- TaskID
- customer_response
- ScriptSelector
- ClosedMessage
- isPCICompliance
- isPCIValidationDone
- senderNumber
- status
- userId
You can view these configurations by clicking on the setting icon on the top right side of the flow canvas.
Email Inbound Flow
This flow is triggered when an email message is received by the Webex Connect platform on an Email asset uniquely identified by the asset Email ID. It is very similar to Live Chat where PCI compliance is checked for, in the email body as well as in any attachments looking for sensitive data.
The flow ends when the CCE taskID gets updated in Engage using the Update Conversation node.
Live Chat Inbound Flow
The sequence and logic of the flow is similar to that of the SMS Inbound Flow, where every message sent by the end user triggers a Search Conversation node to determine if a previous interaction is already in progress. If it is, then an Append Conversation node is invoked to append the incoming message to the existing conversation. else a new conversation is created in Webex Engage. A Pre-Chat form which employs a form template to obtain customer details like Name, Email address and service requested (Or query regarding which, the interaction was initiated), is used to get end user inputs. The same details are used to create a Task in CCE by mapping the form input to determine a Script Selector for the task. Additional ECC or call variables may also be sent as needed to CCE while creating the task.
The flow also checks for incoming messages and attachments sent by end customer for PCI compliance, and warns the user of sensitive data having been detected. The sensitive data detected is redacted in messages, and attachments containing sensitive data are dropped.
Following are the custom variables used in this flow:-
- appid
- message
- inappPayloadObject
- nonPCIComplianceReasonObject
- messagetext
- domain
- conversationId
- errorTechnicalIssue
- errorSendingMessage
- liveChatDomain
- err_msg_toomanyrequests
- parseDataAttachment
- isPCICompliance
- isPCIValidationDone
The liveChatDomain variable should contain the URL of the website (without specifying the protocol like HTTPS) hosting the chat. Eg. support.my-company.com
The flow ends when the CCE taskID gets updated in Engage using the Update Conversation node.
Live Chat Customer Close Flow
This flow is invoked when the customer ends a chat session by closing the chat window or the browser. The flow invokes the CCE End Task node or an Append Conversation depending on whether the Conversation is in Active state (meaning already assigned to an Agent) or if it is still waiting for Agent assignment, which is akin to abandoning the task in queue. If the Agent was handling the task, then the Append Conversation node lets the Agent know that the customer has left the chat session, so that the Agent can finish wrapping up the task before marking it complete.
The custom variables used in this flow are:-
- status
- userId
Live Chat with WebCallback Flow
This flow is similar to the Live Chat Inbound flow, but also offers an option to place a Web Callback / Voice Callback request to the customer instead of waiting for an Agent on the chat medium.
To increase readability, there is a separate page / tab in the same flow that provides the logic which deals with cancelling the chat request and then placing a Web Callback request for a call to be placed to the customer's phone number that was received as input in a Pre-Chat form.
The custom variables used in this flow are:-
- appid
- message
- inappPayloadObject
- nonPCIComplianceReasonObject
- messagetext
- domain
- conversationId
- errorTechnicalIssue
- errorSendingMessage
- liveChatDomain
- err_msg_toomanyrequests
- parseDataAttachment
- isPCICompliance
- isPCIValidationDone
- currentTaskState
- CallbackRequested
- CustomerPhoneNumber
- CustomerName
- CustomerID
- ScriptSelector
- ChatThreadID
- ChatUserID
- errorCallbackFailed
- errorEndTaskFailed
WebCallback CLOSED
This flow is used in conjunction with the Live Chat with Web Callback flow to handle Closed webhook events received from Digital Routing service and message appropriately to end customers who initiated the interaction using Live Chat as a medium. Since there is a possible switch in media, based on customer input, the Closed Webhook event needs to be handled differently. The flow aims at showcasing how this can be achieved in general when switching a digital channel task to a voice based callback from the Contact Center.
The custom variables used in this flow are:-
- TaskContextVariables
- ClosedMessage
- mediaResourceID
- LiveChatThreadID
- LiveChatAppID
- LiveChatUserID
- WebCallbackMessage
- IsWebCallbackRequested
- WebCallbackAgentFound
Facebook Inbound Message Flow
The sequence and logic of the flow is similar to that of the SMS Inbound Flow, where every message sent by the end user using the Facebook Messenger triggers a Search Conversation node to determine if a previous interaction is already in progress. If it is, then an Append Conversation node is invoked to append the incoming message to the existing conversation, else a new conversation is created in Webex Engage. Every Facebook page that is integrated with Webex Connect as an asset will need its own flow to handle conversations that an end customer initiates with a business. An end user interacting with a Facebook page is assigned a unique ID called Facebook PSID (Page Scoped Identifier) which is used as a channel identifier to uniquely identify an end user interacting with the Facebook page and tie all the messages together in a conversation.
The Webex Connect platform provides rich content like carousel messages, quick replies etc that can be used while interacting with an end user, and the template flow showcases how this can be done during self service before escalating the conversation to an agent, based on the user's selection received via a quick reply response. The corresponding Script Selector is passed along to CCE that will indirectly try to assign an agent from a pool of agents having the corresponding skill set to handle the query. The name of the customer as received from the Facebook platform is also passed along into CCE via the CCE Create Task node with an option to additionally pass task context via ECC (Expanded Call Context) or call variables, while creating the CCE task.
The flow ends when the CCE taskID gets updated in Webex Engage using the Update Conversation node.
The custom variables used in this flow are as follows:
- FBpageid
- messagetext
- messengerPayloadObject
- conversationId
- automatedresponse
- errorTechnicalIssue
- customerresponse
- ClosedMessage
- postbackresponse
- attachmentURL
- location
- customerName
- errorSendingMessage
- check_message_content
- actual_message_content
- locationURL
- latitude
- longitude
- contentType
- LocationLabel
- transId
- isPCIValidationDone
- droppedAttachmentCount
- isPCICompliance
- nonPCIComplianceReasonObject
- CustomerEndedAgentMessage
- ScriptSelector
- UtcConvertedTimeStamp
- AssignedAgentID
- ConversationStatus
- CCETaskID
You can view these variables and their default values by clicking on the setting icon on the top right hand side of the flow canvas. You may customize the messages as needed. Some of the variables like FBpageid should definitely be updated to the Facebook Page ID of the Messenger asset created in Webex Connect. While Location can be received in the Connect platform, they currently cannot be shared with an agent since Webex Engage currently doesn't support it - you may choose to store this in other external systems if a Delivery / Pick up location has been shared by an end user interacting with your business.
WhatsApp Inbound Message Flow
The sequence and logic of the flow is similar to that of the SMS Inbound Flow, where every message sent by the end user using the WhatsApp Messenger triggers a Search Conversation node to determine if a previous interaction is already in progress. If it is, then an Append Conversation node is invoked to append the incoming message to the existing conversation, else a new conversation is created in Webex Engage. Every WhatsApp Business account (WABA) integrated with Webex Connect as an asset will need its own flow to handle conversations that an end customer initiates with the business account.
The Webex Connect platform provides rich content like embedded images / videos, quick replies etc that can be used while interacting with an end user, and the template flow showcases how this can be done during self service before escalating the conversation to an agent, based on the user's selection received via a quick reply response. The corresponding Script Selector is passed along to CCE that will indirectly try to assign an agent from a pool of agents having the corresponding skill set to handle the query. The name of the customer as received from the WhatsApp platform is also passed along into CCE via the CCE Create Task node with an option to additionally pass task context via ECC (Expanded Call Context) or call variables, while creating the CCE task.
The flow ends when the CCE taskID gets updated in Webex Engage using the Update Conversation node.
The custom variables used in this flow are as follows:
- messagetext
- messengerPayloadObject
- conversationId
- WANumber
- errorTechnicalIssue
- customerresponse
- ClosedMessage
- postbackresponse
- attachmentURL
- location
- customerName
- automatedresponse
- errorSendingMessage
- check_message_content
- actual_message_content
- locationURL
- latitude
- longitude
- contentType
- LocationLabel
- transId
- isPCIValidationDone
- droppedAttachmentCount
- isPCICompliance
- nonPCIComplianceReasonObject
- CustomerEndedAgentMessage
- ScriptSelector
- UtcConvertedTimeStamp
- customerResponseTimestamp
- postbackResponseTimestamp
- messageTimestamp
- AssignedAgentID
- ConversationStatus
- CCETaskID
You can view these variables and their default values by clicking on the setting icon on the top right hand side of the flow canvas. You may customize the messages as needed. Some of the variables like WANumber should definitely be updated to the WhatsApp Business phone number of the WABA asset created in Webex Connect including country code sans the plus sign. Similar to Facebook Messenger, while Location can be received in the Connect platform, they currently cannot be shared with an agent since Webex Engage currently doesn't support it - you may choose to store this in other external systems if a Delivery / Pick up location has been shared by an end user interacting with your business.
CCE Flows
Conditional execution of Webhook event triggered flows
The Webhook flows that are meant to interact with and send messages back to the customer as the task transitions in the underlying CCE system, can only be associated with one asset at a time per media channels - SMS, Live Chat and Email. That is because a flow can only be associated with a single Live Chat or Email asset at a time, when the flow is made live. The CCE template/representative flows have a pre-defined conditions set per media channel with a sample Asset/AppID, that would not match the assets being employed in the tenant where these flow templates get imported to create new flows. These asset IDs need to be updated to match the ID of the assets or SMS number being used in the tenant. This is an important step before making the flow live to ensure that end to end messaging and other operations like agent assignment and transfer of tasks (Email or Chat) works seamlessly.
Shown below is a sample screenshot of the ROUTED node, that has these conditions specified in the template / representative flows (the same applies for all the other webhook triggered flows as well).
The destination field in the CCE Webhook event maps to the AppID / AssetID of a LiveChat and Email asset ( $(n2.inappmessaging.appId) / $(n2.email.appId) ), or to the Service Number of an SMS asset ($(n2.sms.serviceNumber)) when creating a task using the "CCE Create Task" node. This Asset AppID or number can be determined by navigating to the Assets → Apps or Assets → Numbers menu in Webex Connect.
Conditional execution of flow is absolutely necessary when dealing with more than one asset, to ensure the same CCE webhook event does not trigger more than one flow and cause experience issues for either the Agent or the end customer. In order to facilitate different entry points or assets that one has in the Contact Center, a flow developer can assign the right asset ID in the Start Node of these webhook flows, to ensure that the right flow gets executed based on which asset / entry point (indirectly website or email alias) triggered the task creation in CCE.
If there is only a single asset in the system per media channel, you may remove these conditions before making the flow live to invoke the flow regardless.
Here is a sample screenshot of the ROUTED flow, that has these conditions specified in the template / representative flows (the same applies for all the other webhook triggered flows as well.
Created Flow
This flow is triggered when the Digital Routing Service accepts the task creation request from Webex Connect. This is the first asynchronous event notification sent for a task, by the Digital Routing Service. It does not indicate that the task has been submitted to CCE for queueing and routing, but is just an acknowledgement of the request having been accepted by the Digital Routing service. Depending on the Media Channel on which the task was created, a message is sent to the end customer notifying him / her about the live Agent request.
Depending on whether or not you have Live Chat, SMS or Email channels set up in your system, you may retain or remove the branches and corresponding nodes in this flow before making it live. The Evaluate node is used to extract extension variables associated with the task, so as to be able to send a message / email to the customer on Live Chat and Email channel respectively.
Following are the custom variables used in the flow:-
- TaskContextVariables
- CreatedMessage
- chatThreadID
- mediaResourceID
- CreatedTimeStamp
- EmailSubject
- EmailMessageID
- EmailCCRecipients
- EmailBCCRecipients
- SenderName
- SystemGenerated
This flow is channel-agnostic but the flow designer can choose to make it channel-specific by applying conditions in the Start node.
Queued Flow
This flow is invoked when a task gets submitted to CCE for queueing and routing by the Digital Routing service, or when there are updated task context or Estimated Wait Time (EWT) received from CCE for a queued task, by the Digital Routing service. The first queued event does not have any EWT and is fired as soon as the request is sent to Media Routing (MR) Peripheral Gateway, and before the CCE script gets executed.
An Evaluate node is used to determine whether an EWT has been received in the asynchronous Queued event, and depending on the Media Channel associated with the task, the same gets relayed to the end customer on the respective channel. This is just for demonstrating that the EWT retrieved from the CCE system, can be utilized in the flow to take actions. In the representative flow, every queued event with an EWT gets relayed to the end user, which may be undesirable in the real world.
The following custom variables are used in this flow:-
- TaskContextVariables
- QueuedMessage
- EstimatedWaitTime
- chatThreadID
- mediaResourceID
- QueuedTimeStamp
This flow is channel-agnostic but the flow designer can choose to make it channel-specific by applying conditions in the Start node.
Routed Flow
This flow is invoked on receipt of the Routed event from Digital Routing Service, which in turn is an indication of an Agent being assigned to the task by the CCE Router. The flow uses an Evaluate node to extract the Webex Engage ConversationId from the user_DR_MediaResourceID ECC variable of the Routed event, to use in subsequent nodes.
It invokes the Add Participant node to add the Agent to the existing Conversation with the customer. The customer gets intimated about the same depending on the channel on which the customer is interacting with the Contact Center.
Following are the custom variables used in the flow:-
- TaskContextVariables
- RoutedMessage
- mediaResourceID
- chatThreadID
- RoutedTimeStamp
This flow is channel-agnostic but the flow designer can choose to make it channel-specific by applying conditions in the Start node.
Closed Flow
This flow is invoked when a CCE task get closed by an Agent gracefully, or when the system ends the task abruptly owing to an error or maximum allowed queue time getting elapsed. The Digital Routing Service sends the Closed event in such cases, along with a DispositionCode that can be used to infer the reason for the task closure. For a list of Disposition Codes, refer to the CCE Features Guide.
The flow informs the end customer about task closure on the respective channel, depending on the media channel associated with the task.
Following are the custom variables used in this flow:-
- TaskContextVariables
- ClosedMessage
- mediaResourceID
- chatThreadID
- ClosedTimeStamp
This flow is channel-agnostic but the flow designer can choose to make it channel-specific by applying conditions in the Start node.
Transferred Flow
This flow is invoked on receipt of the Transferred event from the Digital Routing Service. An agent handling a contact, can transfer the task to other queues using the Agent desktop. The transferred event also gets triggered by the system automatically in certain scenarios like RONA (Redirect On No Answer) and Agent Logout with active tasks still in the inbox. The flow first extracts the ConversationID using an Evaluate node, and then removes the Agent as a participant in the Webex Engage platform by invoking the "Remove Participant" node.
The flow then resubmits the task to CCE using the same CCE taskId as was received in the Transferred event, using the Create Task node. It subsequently informs the end customer about the transfer having been initiated on the respective media channel. In case there are any errors while performing the transfer operations, the task is closed and the end user is informed about the failure.
The following custom variables are used in this flow:-
- TaskContextVariables
- TransferredMessage
- mediaResourceID
- FailedTransferMessage
- errorTechnicalIssue
- chatThreadID
- TransferredTimeStamp
- CustomerName
- EmailMessageId
- EmailSubject
- SystemGenerated
This flow is channel-agnostic but the flow designer can choose to make it channel-specific by applying conditions in the Start node.
Updated 16 days ago