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:

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:

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.

3. Go to the Flows tab.
4. Click Create Flow.
5. Provide a name for the flow.
6. Select Upload a flow in the Method drop-down.
7. Click Choose File to upload the required file.

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

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.

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.

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.

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.

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.

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.