Transactional messaging execution and monitoring transactional-messaging-execution

Transactional message execution delivery transactional-message-execution-delivery

Once the message is published and your site integration is done, when an event is triggered, it is assigned to an execution delivery.

{width="60px"}

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.

Related topics:

Transactional messaging retry process transactional-message-retry-process

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:

Event processing retry process event-processing-retry-process

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.

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.

Message sending retry process message-sending-retry-process

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.

Retry process limitations limitations

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.

Monitoring transactional messages monitoring-transactional-message-delivery

To monitor a transactional message, you need to access the corresponding execution deliveries.

Profile-based transactional message specificities profile-transactional-message-monitoring

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.

Related topics: