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]"
}
}