Transactional Send Journeys and the Event Notification Service
Did you already hear about Transactional Send Journeys and the Event Notification Service in Marketing Cloud? Do you wonder what’s in it for you and if it is worth migrating your old triggered sends? Acting on failed sends and connecting a logging system sounds great? Check out what’s possible and how you can set it up!
Transactional Send Journeys
A while ago Salesforce introduced a new type of journey - the Transactional Send Journey. This kind of is a replacement for the triggered sends that you can set up in Email Studio. But to be more accurate it is the missing user interface for the Transactional Messaging API. Sends using that API used to be configurable via the API only which only made it available to developers and didn’t allow marketers to even update the email used. Salesforce changed that by integrating that feature into Journey Builder.
Why even bother using the Transactional Messaging API?
You might ask yourself that question if you already have your transactional sends up and running using the triggered sends feature in Email Studio. But the benefits are obvious to me:
- marketers can easily update the emails in the tool they are comfortable with
- send analytics available in the Journey Builder interface
- sendouts are even faster that high priority sends
- one email is charged as one Super Message (in contrast to 4 supermessages for high priority triggered sends)
- possibility to utilize the Event Notification Service
Setting up a Transactional Send Journey
The setup is as straightforward as you’d think. Just go to Journey Builder, create a new journey and select Transactional Send Journey as journey type. Type the Event Devinition Key - the unique name you use when triggering the send via API - and optionally select a data extension that every send is logged to. I highly recommend doing so to have a better overview of the data that is coming in. This data extension needs to be created from the TriggeredSendDataExtension template in order to be available for that use. Now select an email, activate and you are ready to trigger the first email!
How to trigger the journey
Triggering the journey via API is different to other API triggered journey, but exactly the same as for sends configured through the Transactional Messaging API. Here is what an example request payload to the POST /messaging/v1/email/messages/ endpoint looks like:
{
"definitionKey": "[EVENT_DEFINITION_KEY_OF_YOUR_JOURNEY]",
"recipients": [
{
"contactKey": "[YOUR_RECIPIENT_CONTACTKEY]",
"to": "[YOUR_RECIPIENT_EMAIL]",
"messageKey": "[YOUR-MESSAGE-KEY]",
"attributes": {
"FirstName": "John",
"LastName": "Doe"
}
}
],
"attributes": {
"GeneralInfo": "Something"
}
}As you might anticipate, adding further recipients is as easy as adding another object to the recipients-array. There are two different attributes-properties - one for each subscriber for recipient-related information like the name, a transaction code, etc. and another property that is the same for all recipients and can be used for general personalization or send related data.
The messageKey can be optionally set per individual and used to retrieve the status of the send to this recipient by using the GET /messaging/v1/email/messages/[YOUR-MESSAGE-KEY] API route.
I added a postman collection with all the necessary requests including the ones for the Event Notification Service to my “sfmc-transactional-send-event-notification-service” github repository.
What could be improved?
Emails sent via the Transactional Messaging API lack tracking data being sent to Sales/Service Cloud via Marketing Cloud Connect (just like the old triggered sends did). In my opinion having that sends also appear as Individual Email Results objects would be great in order to have a complete 360 degree view of the customer in a Cross-Cloud environment. I posted an idea on IdeaExchange, so if you also like to see this feature, please cast your vote!
If you have any ideas for further improvement - for this feature or any other one - create an idea on IdeaExchange! Once it received enough votes, Salesforce will have a look at it and maybe put it on the roadmap at some point.
Event Notification Service
As the name suggests, the Event Notification Service (ENS) allows you to get notifications if certain events occur in Salesforce Marketing Cloud. You might wonder where these notifications are sent to and how they look like? You basically need to provide an API endpoint to Marketing Cloud, where the system can send notifications to. You are then responsible for everyting that happens with that notification data.
What do you need to set it up?
You need a publicly accessible HTTP-endpoint that is capable of handling the JSON-data Marketing Cloud sends to you. This can be an endpoint of a logging system, your webserver or any custom program that can be accessed via HTTPs publicly. An example would be hosting a Node.js application on Heroku.
The Setup Process
The setup process is described in the Marketing Cloud documentation and even includes a diagram of the program/request flow in this article: Event Notification Service Activities.
However, this flow could intimidate you if you aren’t familiar with these systems as it looks fairly complex. If you break it down in what’s actually necessary from your end, you end up with only three HTTP requests:
- Register your callback endpoint (→ tell Marketing Cloud where to send the notifications)
- Verify the callback (→ send Marketing Cloud a verification code it sent to your endpoint, so it knows that it belongs to you)
- Subscribe to notifications (→ tell Marketing Cloud which events are interesting for you)
The request for step one is as easy as sending this to /platform/v1/ens-callbacks:
[{
"callbackName": "[NAME_OF_YOUR_FIRST_CALLBACK]",
"url": "[URL_OF_YOUR_ENDPOINT]",
"maxBatchSize": 100
}]During the setup process, you should write some details down when testing or store it somewhere when doing a production setup:
- All the IDs you receive (callback, subscription)
- The signature key you receive (→ this cannot be retrieved later! It is used to verify if events originate from SFMC)
I added a postman collection with all the necessary requests to my “sfmc-transactional-send-event-notification-service” github repository. It also includes the ones for triggering Transactional Send Journey as well as ones for retrieving all active subscriptions and deleting a subscription.
If you don’t like to create a program that serves as callback endpoint, but want to try it out nonetheless, have a look at Requestbin.com, that I explained in my last post “Optimizing Marketing Cloud Develoment”.
What can you do with these notifications?
If an important transactional send fails for some reason it would be nice to set an alternative action, right? So you could use a different transactional email provider or trigger a text message to your recipient for example.
Another use case would be connecting a logger in order to see send statistics for delivered/failed/bounced sends and error messages in the same system the application triggering the mails also logs messages.
Updating the status of the transmission or the current state of engagement (opened, clicked) in the application that triggered the email.
As you see, there are a lot of use cases that absolutely make sense, so you should definitely consider setting this up for your transactional messages.