What is the Multiple Conversations Mode?

The multiple conversations mode allows a single user to keep different support tickets separate within the Web Widget.

Additionally, when this feature is enabled, the user also gains access to the history of resolved conversations, allowing them to view previous interactions, reopen contexts, and review past information.

This functionality was designed for logged-in areas, where each user can be securely identified.

These two features are especially useful when the same client tends to open more than one support ticket at the same time. For SaaS, B2B, or e-commerce companies with high repurchase rates, these features work very well.

📖 How do multiple conversations and their history work?

With the extension of this functionality, the Web Widget displays two tabs for the user:

• Active Conversations

• Conversation History

In the active conversations tab, the user can see and continue all their ongoing conversations or start a new one.

In the history tab, the user can view closed conversations, making it easier to follow up on previous interactions and avoid losing context.

Initially, the history shows the 5 most recent conversations. If the user wants to see older conversations, they can click "See More", and the system will load additional entries in blocks of 5. It is also possible to search conversations using one or more of the following filters:

• Start Date

• End Date

• Ticket ID

How does the customer view multiple conversations?

How does the history work? And how does the customer see it?

🧩 Prerequisites

To activate the multiple conversations mode in CloudChat Web Widget, you need to:

1. Enable User Identity Validation.
   This ensures that each authenticated user on your site is who they claim to be.

2. Integrate the Web Widget script on your site, using the code provided in your Web Widget inbox within the CloudChat dashboard.

⚠️ Important:
The multiple conversations and history feature was designed exclusively for logged-in areas of your site, where there is a unique identifier per user.

It should not be used in public or anonymous areas, as it depends on identity validation to guarantee:

• Correct separation of conversations

• Secure access to history

• User data privacy

⚙️ How to enable multiple conversations and history

1. Access the CloudChat dashboard.

2. Go to Inboxes → Web Widget → Settings.

3. Enable the "Multiple Conversations per User" toggle.

4. Copy the script shown after activation and insert it into your application's HTML (usually before the closing </body> tag).

🧾 Script Example

You can find this script example in Inboxes → Web Widget → Widget Scripts.

🔐 About user_id and identifier_hash

These two parameters are fundamental for user authentication:

• user_id → a unique and permanent identifier of the user in your system (e.g., the UUID from the users table).

• identifier_hash → a cryptographic signature generated by your backend, ensuring the integrity of user_id.

CloudChat uses identifier_hash to validate that the user_id was indeed authenticated by your system and was not tampered with on the client side.

🧮 How to generate the identifier_hash on the backend

The hash should be generated on your backend, never on the frontend, because it uses the private User Identity Validation token provided by CloudChat.
This prevents the token from being exposed in public website code.

import { createHmac } from 'node:crypto';

/**
 * Generates an HMAC SHA256 hash to identify the user
 * @param {string|number} userIdentifier - Unique ID of the user
 * @param {string} hmacToken - Private token provided by CloudChat
 * @returns {string} HMAC hash in hexadecimal format
 */
function generateUserIdentifier(userIdentifier, hmacToken) {
  if (!userIdentifier) {
    throw new Error('userIdentifier is required');
  }

  const identifierHash = createHmac('sha256', hmacToken)
    .update(userIdentifier.toString())
    .digest('hex');

  console.log('Generated Identifier Hash:', identifierHash, 'for user:', userIdentifier);
  return identifierHash;
}

The backend endpoint might look like:

GET /cloudchat/identity-hash?user_id=12345

Returning:

{ "identifier_hash": "d35b5c2e3b7b2f..." }

✅ Best Practices

1. Use a stable user_id (never change the identifier of an existing user).

2. Do not expose the HMAC token on the frontend.

3. Always generate the hash on your backend and send it to the client only when initializing the widget.

4. The identifier_hash should be regenerated every time the widget loads for an authenticated user.