1

REST API is not my forte, can someone help me understand the difference between a REST Call for A) transactional email send b) single send journey c) transactional send journey

I would like to understand which is the best approach for real-time emails. They all seem equally viable.

Thank you patrick

1
  • 1 and 3 are the same thing
    – EazyE
    Commented Jan 21, 2022 at 19:58

1 Answer 1

10

As EazyE states, a = c.

From there onwards, this is a pretty layered question. Definitely you cannot use Single Send Journeys / Transactional Journeys interchangeably.

Opening remark: The term "journey" is used in SFMC pretty liberally these days. Both transactional and single send "journeys" don't actually fully work like journeys. (lets call the classic journey "multi-step" for contrast.)

Yet where Single Send Emails are "dumbed down" multi-step journeys and many capabilities match, transactional journeys work on a completely different engine (transactional API).

Some key differentiators between the two (There could be more differences):

Basic Concept

  • Transactional Journeys superficially look like journeys but under the hood share basically nothing with the concept. The "journey" look was reused as the UI for the newer transactional API, but the similarities end quickly. E.g. There is no versioning, no goals, no paths, not even renaming the "journey" after it's started. They have got their own folder in journey builder where the UI shows slightly different data than for other journeys.

  • Single Send Journeys actually are based on the same foundation as journeys, just limiting capabilities (notably, no versioning), likely to replace one-off email sends at some point.

Supported Send classifications

  • Transactional Journeys work only with transactional send classifications. They simply won't let you pick emails with Commercial Send Definitions
  • Single Send Journeys work with transactional and commercial send classifications

so: If you want to send flat-out advertisement, you need to use single send journeys. If your use case is a double-opt-in email, or an order confirmation etc., transactional journeys are a good option.

Send Framework

  • Transactional Journeys by default send as fast as possible (my rule of thumb = I have it within 10 secs). A send here costs 1 supermessage.

  • Single Send Journeys: You can choose to send fast and expensive ("high priority" Send Definition) for the cost of 4 supermessages or slower ("normal" send definition) for the cost of 1 supermessage. By slower, my rule of thumb is 2-3 minutes due to queueing. This might be subject to change with the new "high throughput" email event scheduled for spring 22 release (havent seen it yet at time of writing).

so: if you send transactional emails, here is a strong argument against single send journeys.

notable difference in Send Frameworks: Tracking

  • Transactional API (and thus Transactional journeys) work entirely differently in terms of getting tracking data. They do not show up in the tracking frontend (Analytics Builder Journey Reports or Email Reports) inside SFMC but give you much better outside visibility through the retrievable messageKey. https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/transactional-messaging-activities.html;

  • Single Send Journeys on the tracking frontend work like Journeys. They can be found in Journey Reports as well as Tracking / Journey Builder Sends, Version 1(*) but do not offer the Transactional API capabilities like Webhooks.

(*) as stated, neither single send journeys nor transactional journeys have versioning, which is a key feature of "actual", multistep journeys. Single Send Journeys, which still use the same framework as multistep journeys, track like them. They just limit the tracking to one, "version 1" tracking folder where multistep would create one for each further version.

Edit: Another related difference: according to this documentation https://help.salesforce.com/s/articleView?id=000333925&type=1 Transactional API is not supporting the default sendlog (which contains an errorCode in case of failed sends). Single Send Journeys do.

EDIT 04-2022: Update by Adam in the comments, you can apparently get it to log sends: https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/transactional-messaging-api.html

Supported Send Types that store 'send time' Data in the Send Log Marketing Cloud allows for appending Send-Time data to the Send Log record via these Send methods:

  • User-Initiated Sends (via Automation Studio)
  • Triggered Sends (inc all Journey Builder types)
  • A/B Test Sends
  • Guided Sends
  • Salesforce Sends

so: If you plan to have reporting externalized or more "on demand", transactional API is likely the stronger offering, but visibility inside marketing cloud is a little different.

Email address update behavior (for reference: https://mc.chat/subscriber-email-address-update-behavior/)

  • Transactional Journeys are always sent to the email you send in the payload (= the data extension used for sending); where necessary, this updates All Subscribers List

  • Single Send Journeys in this respect work like Multi step journeys - They allow you to pick the behavior through Journey Settings: Either the Email on All Subscribers or the Data Extension email can be chosen to "win".

so: if you want 100% confidence that the email address you target from external context goes there, transactional journeys cannot be set up wrong. Single Send Journeys could.

===

see also: Marketing cloud new Transactional Messaging API

Some random notes from tests I did a while back:

  • List detective (everyone's favorite) applies to both send methods, also transactional (so you cannot guarantee sendouts with either of both methods - the final decision still lies with the main man, list detective!) -
{
    "requestId": "7623ddf0-f037-412f-ac42-d02085c45dd3",
    "statusCode": 24,
    "statusMessage": "ListDetectiveExclusion",
    "eventCategoryType": "TransactionalSendEvents.EmailNotSent",
    "timestamp": "2021-10-01T03:06:51.6367",
    "info": {
        "messageKey": "f124af33-f892-4361-85d6-5330d577c555",
        "contactKey": "testListDetective2",
        "to": "[email protected]"
    }
}
9
  • 1
    Well written and explained. I'll add some points of note HTS is not being released in Spring 22, I would never suggest "high priority" with a SSJ or MSJ due to the latency in the journey processing, you would not improve anything in a noticeable manner and consume 4x SM. Dataviews capture all sends, IER are not sent to SFDC for transactional Messaging, and every subscriber sent to has to be a contact. Additional added feature of Transactional sending is the webhooks
    – EazyE
    Commented Jan 22, 2022 at 14:36
  • Sweet, thanks! feel free to answer the contact question here for some closure :D : salesforce.stackexchange.com/questions/328050/… Commented Jan 22, 2022 at 18:39
  • @<EazyE> I think you also answered this one here: salesforce.stackexchange.com/questions/315893/… Commented Jan 26, 2022 at 8:25
  • 1
    I can confirm that 100% because I am looking at a system where we send transactional mailings, and they show up by name in one of the DR reports. Bakcground explanation is likely that datorama reports for SFMC are based on data views, and transactional sends appear there. Commented Feb 9, 2022 at 15:06
  • 1
    Send logging is now available for TXM sends if "auto send logging" is enabled in your BU, per this page -- third bullet in Considerations section. AFAIK, it has to be provisioned separately. Commented Apr 4, 2022 at 14:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .