About ConnectiveOne Integration with Corezoid Through Operator Panel

ConnectiveOne integration with Corezoid allows users who write to Corezoid bots to connect to live operators through ConnectiveOne, and all messages from operators return back to Corezoid. This creates a hybrid solution where Corezoid handles automation, and ConnectiveOne provides operator support.

Context and Problem

In many cases, you need to combine Corezoid automation with live operators:

  • Corezoid handles initial requests and automation
  • When an operator is needed, the request is transferred to ConnectiveOne
  • Operator responds through ConnectiveOne, and messages return to Corezoid

This integration solves the task of combining automation and live operators in a unified workflow.

Key Concepts

Interaction Architecture

The integration works through two ConnectiveOne scenarios:

Scenario #1 (on custom_channel):

  • Receives incoming request from Corezoid
  • Opens chat in ConnectiveOne operator panel
  • Configures event_webhook_url for forwarding events

Scenario #2 (for operator panel events):

  • Receives events from operator panel through webhook
  • Processes events through Action Jail
  • Sends data back to Corezoid through Corezoid API

event_webhook_url Parameter

The event_webhook_url parameter in action operator_panel__connect_to_operator_with_msg allows specifying the URL of another bot where all events from the operator panel will be sent (messages from operator, client, system events).

Approach Options

Direct Integration vs Through Webhook

Direct Integration:

  • ✅ Pros: Simpler implementation
  • ❌ Cons: Less flexibility, harder to scale

Through webhook (recommended):

  • ✅ Pros: Flexibility, logic separation, easy to rework without changing integrations
  • ❌ Cons: More complex initial setup

Why we use webhook: This allows separating event processing logic into a separate scenario and easily adapting to different external systems without changing the main scenario.

Adopted Solutions

Using Action Jail for Event Processing

Action Jail allows processing different event types:

  • message_from_operator — message from operator
  • message_from_client — message from client
  • message_system — system events

Saving original_call_node_body

For callback to Corezoid, original_call_node_body is saved, which is used to return control to Corezoid after event processing.

Implications for Users and Implementation

For Integrators

When configuring the integration, it's important to:

  1. Configure two scenarios — one for receiving requests, another for processing events
  2. Create Action Jail — for processing different event types and sending to Corezoid
  3. Configure event_webhook_url — specify the URL of the second bot for forwarding events
  4. Handle errors — add retry logic and fallback mechanisms

Common Errors

Error: Events do not arrive in the second bot
Problem: event_webhook_url is incorrectly configured
Solution: Check URL and availability of the second bot

Error: Data does not return to Corezoid
Problem: Action Jail is not configured or incorrect Corezoid API URL
Solution: Check Action Jail and Corezoid API URL

Error: Dialog context is lost
Problem: original_call_node_body is not saved
Solution: Add saving and using original_call_node_body for callback

Advantages of This Approach

  • Flexibility: can connect any external system, not just Corezoid
  • Logic separation: operator events do not overload the main scenario
  • Independence: easy to rework only jail processing without changing integrations