Transactional messaging best practices and limitations transactional-messaging-limitations
This section lists the best practices and limitations you should be aware of before starting creating transactional messages.
Permissions permissions
Only users with the Administration role can configure transactional events and access transactional messages.
Event configuration and publication design-and-publication
As you are configuring and publishing transactional events, some of the steps you need to perform cannot be reverted. You need to be aware of the following limitations:
- The available channels for transactional messaging are: Email, Mobile (SMS) and Push notification.
- Only one channel can be used for each event configuration. See Creating an event.
- Once the event is created, you cannot change the channel. Therefore, if a message is not sent successfully, you need to design the mechanism allowing to send it from another channel using a workflow. See Workflow data and processes.
- You cannot change the targeting dimension ( Real-time event or Profile ) after the event is created. See Creating an event.
- It is not possible to rollback a publication, but you can unpublish an event: this operation makes the event and the associated transactional message inaccessible. See Unpublishing an event.
- The only transactional message that can be associated with an event is the message that is automatically created upon publishing that event. See Previewing and publishing the event.
Number of transactional messages transactional-message-number
The number of published transactional messages can have a significant impact on your platform. For optimal performance, the number of published transactional messages should remain under 100, otherwise performance degradation can be encountered. To ensure this, unpublish or delete any unused transactional messages in order to meet the aforementioned guardrail. See Unpublishing a transactional message and Deleting a transactional message.
To ensure best performance, you can also unpublish or delete unused events. Indeed, unpublishing or deleting an event will also unpublish or delete the corresponding transactional message(s), and its sending and tracking logs if any. See Unpublishing an event and Deleting an event.
Personalization personalization
The way you can personalize a message content depends on the type of transactional message. Specificities are listed below.
Event-based transactional messages
- The personalization information is coming from the data contained in the event itself. See Event-based transactional message configuration.
- You cannot use Unsubscription link content blocks in an event transactional message.
- Event-based transactional messaging is supposed to use only the data that are in the sent event to define the recipient and the message content personalization. However, you can enrich the content of your transactional message using information from the ÃÛ¶¹ÊÓƵ Campaign database. See Enriching an event and Personalizing a transactional message.
- As event transactional messages do not contain profile information, they are not compatible with fatigue rules, even in the case of an enrichment with profiles.
Profile-based transactional messages
- The personalization information can come from the data contained in the event or from the reconciled profile record. See Profile-based transactional message configuration and Profile-based transactional message specificities.
- You can use Unsubscription link content blocks in a profile transactional message. See Adding a content block.
- Fatigue rules are compatible with profile transactional messages. See Fatigue rules.
Product listings
Note that product listings are available in transactional email messages only. See Using product listings in a transactional message.
Branding permissions-and-branding
When it comes to branding management, transactional messaging enables less flexibility than standard messaging. ÃÛ¶¹ÊÓƵ recommends linking all brands used in transactional messages to the All organizational unit. For more on this, read the detailed explanation below.
When editing a transactional message, you can link it to a brand to automatically apply some parameters such as the brand name or the brand logo. The Default brand is selected by default in the transactional message properties.
All objects (including branding) used in a transactional message must be visible from the Message Center organizational unit, meaning that these objects must be in the Message Center or All organizational units.
However, if the brand selected in the message properties is linked to an organizational unit which is different from Message Center or All, this will cause an error and you will not be able to send the transactional message.
Therefore, if you want to use multi-branding in the context of transactional messaging, you should link all brands either to the Message Center organizational unit or to the All organizational unit.
Exporting and importing transactional messages exporting-and-importing-transactional-messages
- To export a transactional message, you need to include the corresponding event configuration when creating the package export.
- Once the transactional message is imported through a package, it is not displayed in the transactional message list. You need to publish the event configuration in order to make the associated transactional message available.