Flow Configurations

While you can always configure your own flows for handling incoming inquiries over digital messaging channels (such as SMS, Live Chat, 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 11 representative flows as listed below:

Flow NameDescriptionAdditional context
Email_Inbound_FlowUsed 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_FlowUsed 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_Abandon_Close_FlowUsed 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.
SMS_Inbound_FlowUsed 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.
Live_Chat_Inbound_With_Web_Callback_FlowSimilar 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 CLOSED_Webhook_for_Web_Callback_Flow
CREATED_FlowUsed 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_FlowUsed 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_FlowUsed 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_FlowUsed 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.
CLOSED_Webhook_for_Web_Callback_FlowUsed 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.
TRANSFERRED_FlowUsed 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:-

  1. 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.
  2. 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.
  3. 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:
ChannelField Name in Create Task nodeUnderlying ECC/Extension variable populated in Task payload
SMSConversation Iduser_DR_MediaResourceID
SMSCustomer Nameuser_DR_CustomerName
Live ChatConversation Iduser_DR_MediaResourceID
Live ChatCustomer Nameuser_DR_CustomerName
Live ChatLive Chat Thread IdChatThreadID
EmailConversation Iduser_DR_MediaResourceID
EmailCustomer Nameuser_DR_CustomerName
EmailEmail Message IdEmailMessageID
EmailSubjectEmailSubject
EmailEmail CCEmailCCRecipients
EmailEmail BCCEmailBCCRecipients
Web CallbackConversation Iduser_DR_MediaResourceID
Web CallbackCustomer Nameuser_DR_CustomerName
Web CallbackLiveChatUserID*LiveChatUserID
Web CallbackLiveChatThreadID*LiveChatThreadID
Web CallbackLiveChatAppID*LiveChatAppID

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.

To create a flow using upload a flow option:

  1. 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.
  2. Click the service and navigate to Service Dashboard.
  1. Go to the Flows tab.
  2. Click Create Flow.
  3. Provide a name for the flow.
  4. Select Upload a flow in the Method drop-down.
  5. Click Choose File to upload the required file.

  1. 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

  1. Open the required flow in the flow editor.
  2. Double click the pre-built Cisco Contact Center Enterprise (CCE) nodes one at a time and provide authorization for the concerned node.
  3. Keep the Method Name as is.
  4. 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.
  5. Refer to the pre-built integration node documentation to configure other fields in the node.
  6. 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 Message 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.
1343

SMS Inbound Message Flow

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.

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.

745

Created Flow

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.

1000

Queued Flow

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.

1195

Routed Flow

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.

1189

Closed Flow

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.

1201

Transferred Flow

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.

Live Chat 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 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.

1471

Live Chat Inbound Message Flow

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 Abandon 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.

578

Live Chat Close Flow

The custom variables used in this flow are:-

  • status
  • userId

Live_Chat_Inbound_With_Web_Callback_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

CLOSED_Webhook_for_Web_Callback_Flow

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

Email Inbound Message 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.

1463

Email Inbound Message Flow

The flow ends when the CCE taskID gets updated in Engage using the Update Conversation node.

Conditional execution of Webhook event triggered flows

The Webhook flows that are meant to interact 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. 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. However, conditional execution of flow is absolutely necessary when dealing with more than one asset, to ensure the same webhook event does not trigger both flows and cause experience issues for either the Agent or the end customer.
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.