Conversation Studio

Conversation Studio is ExpertFlow's visual flow builder that replaces the legacy Python-based Conversation Controller. Unlike the previous system that required manual modification of training files for each conversation flow, Conversation Studio provides an intuitive Node-RED based interface where business users can design and modify conversation flows through a visual drag-and-drop editor.

Key Benefits over Legacy Controller:

Visual Flow Design - Create conversation flows using a graphical interface instead of editing code files
Real-time Modifications - Update flows instantly without system restarts or file deployments
Business User Friendly - Non-technical users can build and modify conversation logic
Centralized Management - All conversation flows managed in one unified platform

Key Terminology

Before diving into the technical details, here are the essential terms used in Conversation Studio:

Flow - A visual representation of conversation logic connecting various nodes
Intent - Events processed by Conversation Manager (e.g., CONVERSATION_STARTED, AGENT_SUBSCRIBED)
Slots - Memory storage in Redis that holds current event details for a conversation
Entities - Data objects containing conversation context and event information
Nodes - Building blocks that perform specific functions within a flow

How to Access Conversation Studio

Please follow the config guide to deploy and access Conversation Studio.

What Conversation Studio Does

Conversation Studio works as:

Intercept for messages and performs actions as per the defined flow.
Flow builder for solutions such as IVR, campaigns and forms(surveys).
Acts as a conversation controller to control conversation from start to end.

How conversation studio Controls Conversation

The conversation studio controls the conversation flow from creation to closure. It monitors and controls the communication exchange between the customer and the business resources (Bot, Agent) and takes decisions upon intents passed by the Conversation Manager. The intents are basically the events that are processed by Conversation Manager. The events on which we want to perform custom actions are then passed to Conversation Studio. The list of all events are mentioned here.

The studio gives control to the business to customize the behavior of conversation handling. For example, send a greeting message as customer joins a conversation or send a survey message to the customer when agent leaves.

The Conversation Studio decides to close a channel session at any point in time, based on the bot training data. For instance, it may close a session if one of the following happens:

The customer leaves the chat
The agent leaves the chat and no one else is in the conversation
Customer response timeout expire

The sequence of events in given as follows:

Conversation Manager delivers the event to Conversation Studio by calling the exposed endpoint /intent with the payload in below format
1. Conversation Studio exposes a webhook at /intent with the POST method, that can be used by Conversation Manager to deliver the actions occurring within the system, for example, CONVERSATION_STARTED, AGENT_SUBSCRIBED etc.

CODE

{
  roomId: RoomId,                   // Type: string
  conversation: ConversationObject, // Type: Object
  intent: EventName,                // Type: string
  entities: EntitiesObject,         // Type: Object
  metadata: MetadataObject          // Type: Object
}

Conversation Studio does the internal processing and passes the control to the relevant INIT node with the payload in below format:
1. It merges the slot in redis for this given roomId and update the slots object in this msg object as well. Slots are just the place in memory(Redis) to hold the current event details.

CODE

msg = {
  _msgid: "...",
  req: { ... }, // Request object
  res: { ... }, // Response wrapper
  payload: {
    roomId: "12345",
    conversation: {},
    intent: "CHANNEL_SESSION_STARTED",
    entities: {},   // Object of Map Type that includes the complete CimEvent object as value agains the key "cimEvent".
    metadata: {},
    messages: [],
    slots: { ... }
  }
}

Init Node then triggers the complete flow.
If any action needs to be executed, it is delivered to the Conversation Manager on the webhook /controller-webhook

CODE

{
  "conversationId": "<conversation_id>",
  "channelSession": "<last_used_channel_session>",
  "messages": [
    {
      "mode": "",
      "body": {
        "type": "ACTION",
        "name": "<ACTION_NAME>",
        "data": {
          /* action-specific data */
        }
      }
    }
  ]
}

‌

Databases

Conversation Studio uses the following database for its working.

Redis: Conversation Studio stores the slots linked to a room, messages cache and context storage in the Redis.

Custom Plugins

The Conversation Studio uses following plugins for its functionality

node-red-auth-keycloak: The custom plugin to authenticate and authorize users from Keycloak.
node-red-context-redis: This is a custom context storage that is used by default in the Conversation Studio instead of memory or localfilesystem.
node-red-resilient-hooks: This hook ensures that messages currently being processed by the Conversation Studio are not lost between flow changes by the user

Studio Nodes

Conversation Studio is built through Node-RED which is a programming tool for wiring together hardware devices, APIs and online services.. It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.

In Node-RED a node is a fundamental building block encapsulating a specific functionality. ExpertFlow provides businesses with the following nodes that they can connect in different sequences to define custom behavior of the system. Following are the three main studio nodes. There are many subnodes within these main nodes.

‌