Communications Log
  • 28 Oct 2021
  • 3 Minutes To Read
  • Dark
  • PDF

Communications Log

  • Dark
  • PDF

Every notification sent to a client, user, or third party system is saved in Mambu for auditing and troubleshooting purposes. You can search your complete notification history by state, sender and date, which will make it easy for you to know which messages were delivered, when, to whom and what the contents of the message were. Manual notifications will indicate the name of the user who sent it while any automated notifications will all have the sender Mambu.

If you do not already have a shortcut to the notification log in your instance, administrators can add this to the menu bar by clicking the small cog icon at the far right to access the Manage My Views menu and the plus icon to add a new view with Type>Communications

Access a filterable log of all notifications

You can also apply filters on those messages, edit the displayed columns or export to Excel. If you chose to export the list to Excel it will include the full message text. The message subject is available if you click more in the Message column to view the full message.

You can also view a filtered communications log by accessing the detail pages for:

  • Clients → you’ll see all the manual and automated notification messages sent to them.
  • Groups → you'll see all the manual notifications sent to the general group contact address as well as automated Webhooks sent based on group activity.
  • Users → you’ll see all the manual messages sent by that user as well as automated messages sent to them based on client activity.

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.

Resending Failed Messages

If your notification gateway was not available when the message was sent (SMTP server was down, SMS provider was offline etc.), you can resend a message to the client.

By clicking on the Failed State column or on the more button from the Message column, a dialog will be shown with the possibility to resend the message. If you resend the message 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.

You can also use our APIs for checking the status of and resending notifications. For example, sending a POST request to the /api/communications/messages:searchendpoint with this body:

    "field": "state",
    "operator": "EQUALS",
	"value": "FAILED"

will return an array of all failed email messages. The response can be used to create the body for a POST request to the /api/communications/messages:resend endpoint to trigger a resend of these messages.

For more information on this or any other API, please consult our dedicated API documentation.

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.

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.

Field Description
maxRetries The max number of retries to perform. -1 indicates to retry forever.
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.

By default the maximum number of retries to be performed is set to 4. 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.

Please Be Aware
Organizations on a shared environment are not currently able to adjust the default settings. Organizations with a dedicated environment can decide to disable this policy or to change the configuration settings, if needed.

Was This Article Helpful?