Once the message is published and your site integration is done, when an event is triggered, it is assigned to an execution delivery.
An execution delivery is a non-actionable and non-functional technical message created once a month for each transactional message, and each time a transactional message is edited and published again.
A temporarily undelivered transactional message is subject to automatic retries that are performed until the delivery expires. For more on the delivery duration, see Validity period parameters.
When a transactional message fails to be sent, there are two retry systems:
When an event is triggered, it is assigned to an execution delivery. If the event cannot be assigned to an execution delivery, the event processing is postponed. Retries are then performed until it is assigned to a new execution delivery.
A postponed event does not appear in the transactional message sending logs, because it is not assigned to an execution delivery yet.
For example, the event could not be assigned to an execution delivery because its content was not correct, there was an issue with access rights or branding, an error was detected on applying typology rules, etc. In this case, you can pause the message, edit it to fix the problem and publish it again. The retry system will then assign it to a new execution delivery.
Once the event has been assigned to an execution delivery, the transactional message can fail due to a temporary error, if the recipient’s mailbox is full for example. For more on this, see Retries after a delivery temporary failure.
When an event is assigned to an execution delivery, it appears in the sending logs of this execution delivery, and only at this time. The failed deliveries are displayed in the Execution list tab of the transactional message sending logs.
Sending logs update
In the retry process, the sending logs of the new execution delivery are not immediately updated (the update is performed through a scheduled workflow). It means that the message could be in Pending status even if the transactional event has been processed by the new execution delivery.
Failed execution delivery
You cannot stop an execution delivery. However, if the current execution delivery fails, a new one is created as soon as a new event is received, and all new events are processed by this new execution delivery. No new events are processed by the failed execution delivery.
If some events already assigned to an execution delivery have been postponed as part of the retry process and if that execution delivery fails, the retry system does not assign the postponed events to the new execution delivery, which means that these events are lost. Check the delivery logs to see the recipients that may have been impacted.
To monitor a transactional message, you need to access the corresponding execution deliveries.
To view the message delivery log, click the icon at the bottom right of the Deployment block.
Click the Execution list tab.
Select the execution delivery of your choice.
Click again the icon at the bottom right of the Deployment block.
For each execution delivery, you can consult the delivery logs as you would do for a standard delivery. For more on accessing and using the logs, see Monitoring a delivery.
For profile-based transactional messages, you can monitor the following profile information.
Select the Sending logs tab. In the Status column, Sent indicates that a profile has opted in.
Select the Exclusions logs tab to view recipients who have been excluded from the message target, such as addresses on denylist.
For any profile that has opted out, the Address on denylist typology rule excluded the corresponding recipient.
This rule is part of a specific typology that applies to all transactional messages based on the Profile table.