Developer documentation for the multi-conversations beta program | Community
Skip to main content

Developer documentation for the multi-conversations beta program

  • April 13, 2023
  • 1 reply
  • 0 views

Technical requirements for participating in the multi-conversations beta program

In order to use the multi-conversation feature, customers must upgrade to the v2.10.0 or a later version of the Zendesk SDKs. Note that end users with older versions of the Zendesk SDK will not be able to use the multi-conversation feature. These customers will continue to have the existing single conversation experience in messaging.

Enabling and disabling the multi-conversations

As part of your onboarding to the program we will enable the feature for your account. Throughout the program, you will have the control to disable it and enable again anytime by using our Sunshine Conversations API.

Please see more information in this article about how end user experience and agent experience get impacted when multi-conversations is disabled.

Here is the API documentation for the endpoint customers need to use in order to enable/disable multi-conversations. Configuring the 'canUserCreateMoreConversations' parameter to FALSE will disable the feature, and TRUE will enable it.

Note that using the API requires a Conversations API key which can be created inside the Admin Center. (Visit this help centre article for more information on creating a Conversations API key.)

Presenting the messaging screen for multi-conversations (for iOS)

With the multi-conversations feature enabled, calling the messagingViewController() method will return a view controller that either displays a particular conversation screen or the conversations list screen, depending on the use case. You can use your preferred presentation style (push, modal) to present the view controller. Note that you must embed the view controller in a UINavigationController if presenting modally.

How to test the feature before rolling it out to your customer base

Beta participants can test the feature via their Sandbox test accounts. Once the beta program is enabled by us for your test account, you can configure the 'canUserCreateMoreConversations' parameter as explained above, by using the Conversations API key you will get for your test account from the Admin Center.

Technical limitations of the beta program

Below are some limitations for customers who use Sunshine Conversations APIs.

  1. Our V1 Sunshine Conversations APIs don’t support multi-conversations feature, and they shouldn’t be used by Multi-conversation Beta participants as it would cause unexpected results.
  2. Customers should not merge users, as the multi-conversations feature currently doesn’t support user merging. Merging users will cause unexpected results.

1 reply

Viachaslau11

We are part of this program and we consider this feature a must have for two purposes: 

  1.  when a customer already has a chat with an issue that still needs to be resolved, but they have a new issue and therefore should be able to create a new chat;
  2. when we create a proactive message to a customer having another active chat (e.g., their account is locked and we want to help).

In practice, some of customers misuse the feature and by the time of public announcement, we would like to have some improvements:

  1.  customization. This is especially relevant when we have a queue and many clients start creating new chats, worsening the situation.  For example, the ability to limit the number of simultaneous chats of the same client in New status. Or using AI to determine if a New chat is related to the same issue and automatically merge them while it is still in the queue before assigning it to an agent.
  2. We would also like to change the behavior of the function in case we merge chats. Now they are not merged on the client side.  
  3. Clients complain that they get lost in the list of chats and can't find the right one. We would like clients to see the status of the chat. Let's say if a chat is in Pending status, then this chat should be highlighted, as it requires the client's attention. Also if the status is On-hold, it would be obvious to the client that it is not closed and we are still working on it. If the status is completed or closed — it's also should be visible.
  4. Closed chats should be moved to the "archive" folder, and for this status "closed" do not give the client the opportunity to send a new message. 
  5. In general we'd like to have settings to determine when customers can send new messages depending on chat status. 
  6. Often clients ask to be able to hide some chats on their side.