Week of November 8th
New updates: User Management, Third Party Bots & SMS Update
Enhancements
A new column has been added to the User Management module. It indicates if a user is enabled or disabled in the account. A filter above that column allows users to filter the users based on their enabled/disabled state. This enhancement is enabled by default.

User Management Updates
Features
Public Link Shorteners (SMS best practices)
Be cautious when using public URL shorteners like Bitly or TinyUrl. Many spammers use these services, which has prompted US carrier policies to strongly discourage their use.
Risk Alert:
Utilizing public URL shorteners can increase the likelihood of your messages being filtered or marked as potential spam, thus reducing their effectiveness.
Immediate Action:
If you are currently using public link shorteners, we highly recommend switching to a brand-owned link shortener to protect your messaging integrity and reach. This proactive step will greatly benefit your audience's experience and the success of your SMS campaigns.
Enhancements
Reduce latency when processing consumer messages
A delay in the processing bot responses was removed when handling long bot messages, resulting in a slightly improved response latency performance
IBM Watson Connector: Support for Date response type
The IBM Watson connector will now recognize Watson responses of type "Date" and forward them to the LivePerson Messaging system as rich content of type Date Picker.
Fixes
Introduce separate rate limit when handling files as bot responses
When sending an array of files as a consumer to a bot connected via Third-Party Bots, a spam protection might have mistakenly triggered, discarding several files. With this release, file messages are not ignored when being sent as a list.
Fix race condition when joining a conversation and send a message via public API at almost the same time
There was a race condition where the message event was received before the conversation change event in the joinConversationCommand
, resulting in missed processing of conversation details. As a fallback, the worker fetched details from the Messaging History API, which was slow and not always reliable, potentially leaving conversationDetails
empty.
The fix now ensures up to 3 retries to verify that the conversation is connected before resorting to the Messaging History API, leading to the correct order of handling events.