11-9-2022 Release

Textel Platform Updates

New Keyword Responder Action | Auto-Assign Conversation to User

We have added another action that can be configured on a Keyword Responder. With this new action, clients can now set up a Keyword to automatically assign the incoming conversation response to a specific user.

This can be useful in scenarios where a client wants specific responses to go to a user in our platform instead of going into the unassigned queue.

To set this up, just go to the Keyword Responder setup page and configure the new option under the Actions menu.

NOTE: All actions can work together. They are not mutually exclusive. You could have a single Keyword Responder that:

Opts someone in
Adds them to a specific contact list
AND assigns their next response to a specific user

New Public API Endpoint | Set Consent Status (Opt In/Out Status)

We have added two new API endpoints to our Public API. One is an Account-wide consent status change. The other is a Line-level consent status change. Both of these endpoints allow our clients and integration partners to use our API to update the opt in or out status for one or more contacts. This is going to be especially helpful for various CRM and POS applications who have contact data stored elsewhere and need to be able to update our system.

IMPORTANT NOTE: In order to preserve the integrity of opt in/out tracking and enforcement, we only allow a change in status IF there was not already one defined. Meaning, we will not allow clients to blanket change opted out contacts to opted in via the API. If a contact has a status set of opted in or opted out, it cannot be changed via our API. It only applies to setting it for the first time. Once the status is set it can only be influenced by the contact texting in.

Conversation Inbox Updates On Transfer

We have made a small adjustment that now the label that shows who a conversation is assigned to in the inbox is updated in real-time when a conversation is transferred or released to the queue.

Improved Send Message and Blast Send Rate Performance

In a continual effort to improve our platform and optimize various important pieces of our platform, we have put some focus on our send message performance and our ability to scale our send rates for Blast.

Improve SendMessage Performance
1. We have now cached several things when sending Blasts that do not require us to hit the DB every time. These things include, Outbound line info and attachments.
2. We also improved our logging of this method and endpoint to continuously monitor our thresholds.
3. This took us from around ~675ms to ~200ms per send message call.
Optimize Blast Send Rate
1. To scale our Blast send rate we did two things:
  1. Split our Conversation send queue from the Blast send queue on the same lines
  2. Create a queue partitioning system that allows us to use multiple queues for the same line to process messages simultaneously. So instead of a single send queue per outbound line for Blast (that sends 5 messages per second), there could be up to 4-5 queues that process sends simultaneously. This is what allows us to hit a send rate of 25 messages a second for toll free numbers as an example.

Bug Fixes

MEDIUM: User Usage Report | User Count Incorrect & Causing Errors
MEDIUM: CRUDy | Bulk Line Import may be creating duplicates
MEDIUM: CRUDy | Nice Account Integration Settings, creating duplicates
MEDIUM: Table date time display in Safari
MEDIUM: Scheduled Twilio Messages Not Sending | Update Common MessageSchedule Microservice

Page updated

Google Sites

Report abuse