Skip to content

Chat Router

The term "router" refers to the ability to connect an external chat router, separate from Rox.Chat - a service that determines which agent or department should handle the chat. Immediately after creation and before the automatic distribution of the chat, its information is first sent from Rox.Chat to this router, which then decides where to direct the chat.

Basic Rox.Chat supports only one router inside Chat Backend using the suds library. More routers can be supported as part of additional work, please contact technical support for more information.

Components of the Router

The router's functionality consists of the following components:

  • The custom_router_schema_url parameter in the account config settings contains the URL of the external router to which the Rox.Chat Server will connect.

  • If a router is specified in the account, during the initialization of the Chat Backend, the communication object between the account and the router is also initialized.

  • A special chat state: ROUTING. It indicates that the chat is in routing and awaits a decision from the router. The chat state is clearly displayed in the Chat Lifecycle Diagram.

  • Each department has a special parameter called routing, which can take the values True or False. Sending a chat to the router only occurs if the department of that session has it set to True.

  • Routing to the external router occurs after creating the chat and meeting several conditions: for instance, a router must be specified and initiated in the account, routing must be allowed in the department, a bot hasn't taken the chat, etc.

  • Information is sent to the router in SOAP (XML) format according to the WSDL specification. The packet includes the chat ID, channel type, user ID (for Telegram and WhatsApp this is the channel ID, in other cases it's either the provided visitor ID, the channel ID, or it's absent), the first message from the visitor, and the chat's starting page.

  • In response, the router sends Rox.Chat a data packet indicating what to do with the chat. Options: skill = route to a department (triggers the sys.routing_to_department event), employee = route to an agent (triggers sys.routing_to_agent). The packet also contains siebelId (visitor ID in CRM Siebel) and taskId, which enrich the visitor object.

  • If a failure occurs during routing, the sys.routing_failed event is triggered.

  • If a visitor sends their contact details with a phone number in the Telegram channel, this phone number is separately sent to the router, but not for routing purposes. Instead, it's to enrich the session (visitor object) with the siebelId corresponding to that phone number.

  • If a chat is taken off a bot, it's sent back to the router.

  • There's an option to ensure that if a chat is routed for more than 30 seconds, it's taken off the router and sent to the general queue.

Interaction with System Components

  1. Interaction with the chat server:

    • Account settings custom_router_schema_url and custom_router_timeout are used;

    • The department key of the passed chat is taken, the department is selected by the key, and its routing settings are checked;

    • Chat events sys.routing_to_operator, sys.routing_to_department, and sys.routing_failure are used;

    • The router is expected to transmit a department key or agent ID via the skill and employee parameters, respectively. If skill is detected, the department with this key (department_key) is searched. If such a department is found, the chat is routed to it, otherwise the sys.routing_failed event is called. If skill is not detected, but employee is detected, an agent with this ID is searched for. If such an agent is found, the chat is routed to it, otherwise the sys.routing_failed event is triggered.

    • The system enriches the visitor object with the siebelId and taskId fields if they are present in the response transmitted by the router;

    • The following data is used to generate a request to the client router: chat ID, address location, chat.channel location setting, client channel, client phone field, client provided id, session platform, address URL, client name in the channel, client provided phone, client ID in the channel.

    • Chat ID is used in logging.

  2. Interaction with the database: there are no direct database queries, passed arguments, and data from memory are used.

  3. Interaction with company routers: the connection is made via a web service (the client is created using the suds library), the WSDL document address for each router is specified in the account settings custom_router_schema_url. The custom_router_timeout settings store request timeout values.