- 08 Aug 2024
- 3 Minutes To Read
- Print
- DarkLight
- PDF
Managing Notifications
- Updated On 08 Aug 2024
- 3 Minutes To Read
- Print
- DarkLight
- PDF
Mambu saves every email, SMS, webhook, and streaming API notification for auditing and troubleshooting puposes.
To view the communication log with a full list of all notifications that have been sent for your tenant you must have access to a menu item with the type Communications. For more information, see Menu item types and permissions as well as Creating menu items.
Managing the communication log
The communication log allows you to:
- Apply filters to the list of notifications.
- Edit the displayed columns. For more information, see Customizing Columns.
- Export to Excel. For more information, see Exporting to Excel below.
- Create additional custom views to always have easy access to a filtered list of notifications. For more information, see Custom Views.
Notification information
Each notification displays some default information including the state of the notification, the sender, and the date.
Notification States
State | Description |
---|---|
QUEUED , WAITING , SENDING_ASYNC | The notification is waiting to be sent. |
SENT | The notification was sent successfully. |
FAILED | The notification was not sent to the designated target. |
Sent by
Automated notifications will all have the sender Mambu while manual notifications will indicate the name of the user who sent it.
Message contents
To view the full message contents of a specific notification, you must select the more link. In the case of emails, this will also display the email subject.
Exporting to Excel
To export the list of notifications, select the Export to Excel icon .
The exported list will include the full message text.
Viewing client, group, or user communication logs
To view the communication log containing all the notifications for a specific individual client, group, or user:
- Go to the specific individual client/group/user detail page.
- Select the Communications tab.
Resending failed messages
If the state of a notification is FAILED
then you may resend the notification either through the Mambu UI or API v2.
If you resend a message,s you will not overwrite the entry for the initial failed message, Mambu will try to send the notification again and create a new entry with its own state and sent date, retaining the log entry of the original message for further investigation.
When resending messages, the system will use the previously generated version of the message content so there is no need to worry that the message content will be any different than what was originally intended to have been sent.
Resending failed messages via Mambu UI
To resend a failed message using the Mambu UI, you may either:
- open the message detail view by clicking the Failed text in the State column and selecting Resend, or,
- select the more link from the Message column, and select Resend in the dialog.
Resending failed messages via API
To resend a failed message via Mambu API v2, you must make a POST
request to the /communications/messages:resend
endpoint. For more information see the resend endpoint in the API Reference.
Example
To return an array of all failed email messages you may send a POST
request to the /api/communications/messages:search
endpoint with the following body:
[
{
"field": "state",
"operator": "EQUALS",
"value": "FAILED"
},
{
"field":"type",
"operator":"EQUALS",
"value":"EMAIL"
}
]
Then you can use the response from your first request and place it in the body of another POST
request to the /api/communications/messages:resend
endpoint to trigger a resend of all these messages.
Automatic retry mechanism for failed communications
Mambu supports an auto-retry policy to resend all failed SMS, email, or webhook notifications. With this mechanism, we will mitigate potential communication outages by retrying any failed notification a number of times.
By default, Mambu will retry 5
more times after the initial attempt. Between each retry there is a delay range configured (measured in seconds) using an exponential backoff strategy to permit the servers to wait for longer intervals of time for each retry attempt. Using the default values, a message will be retried after 2
, 6
, 18
and 54
seconds, after which it is considered failed.
The parameters that determine how the retry mechanism functions are shown in the table below.
Field | Description |
---|---|
maxRetries | The max number of retries to perform, counted from 0 to 4 . -1 indicates to retry forever. The default value is 4 . |
backOffDelay | The delay between retries, exponentially backing off to the maxDelay and multiplying successive delays by a factor. |
backOffMaxDelay | The max delay between retries. |
delayFactor * backOffDelay | Time to wait before retrying messages. |
Customers do not have access to adjust these settings on their own.
If your organization is on a shared environment, you cannot adjust the default settings.
If your organization is on a dedicated environment, please contact us through Mambu Support to discuss adjusting any of the above settings.