Mastering Triggered Sends in Marketing Cloud: A Comprehensive Guide
Dilip Sharma
Marketing Cloud Consultant | Salesforce Marketer, Sawai Madhopur- Group Leader | Trailblazer Mentor | Marketing Cloud Practice | Pardot | #SFMC Expert
Understanding Triggered Emails in Marketing Cloud
A triggered email is an automated message sent to a contact in response to a specific user action or event. These emails are delivered promptly to align with user behaviors, aiming to provide timely and relevant content that increases engagement and conversion rates. Unlike scheduled emails, triggered emails are initiated by user actions or specific conditions being met, making them highly targeted and relevant to the recipient's behavior, preferences, or interactions with a website, app, or platform.
For example, a triggered email might be sent as a confirmation message following a customer’s purchase, newsletter sign-ups, abandoned carts, or other user activities such as reaching a new loyalty tier.
As the developer, you are responsible for identifying the events that trigger the email and creating the code to initiate the triggered email interaction.
The API call executes the interaction, which sends the email.
To initiate the Salesforce Marketing Cloud (SFMC) triggered send interaction, the API call determines the specifics of when and to whom the email is sent. This can be achieved using Marketing Cloud’s internal scripting languages such as WSProxy, AMPscript, or Core Library functions. Additionally, third-party applications can use the REST API after establishing a connection through an installed package in Marketing Cloud. Your code must capture any subscriber information necessary to send the message, with the subscriber email address being the minimum requirement.
A triggered email has two components that you create in SFMC:
The Triggered Send Definition defines the email content and delivery settings and the overall behaviour each time it gets triggered. The system uses this information each and every time an email is triggered. It will have a unique External Key value that is used by the API calls to initiate the interaction. Remember, the definition of what actually triggers the interaction to send the email is maintained using API calls.
Before you can use the Marketing Cloud API to trigger emails, you need the following information:
Did you know that when you create a Journey Builder email, a triggered send is automatically created? Activating the journey creates the Triggered Send Definition that the journey’s email activity uses. Activating a new journey version defines a brand new Triggered Send.
You can see this all for yourself by going to Email Studio > Interactions > Messages > Email > Journey Builder Sends.
You can modify the email’s content, then restart the triggered send to re-enable sending within the journey.
Triggered Sends differ from Scheduled Ad-hoc Sends because they are active over a period of time. This is a crucial point of distinction. Triggered Sends do not use the same Send Definitions as User Initiated sends, they use Triggered Send Definitions. This is reflected in numerous areas within the platform:
Because of this key point of differentiation, the way we report on Journey Emails and Triggered Sends needs to be modified compared to standard “once and done” user initiated sends.
To begin with, the Primary Keys for identifying Triggered Sends in SFMC reporting are the TriggeredSendCustomerKey and/or the TriggeredSendDefinitionObjectID [note that in the Job DataView this field is referred to as TriggererSendDefinitionObjectID]. These keys are used to uniquely identify a triggered send.
SFMC reports on Triggered Sends using these keys rather than JobID and this enables you to track the performance and metrics associated with a specific Triggered Send over its lifetime. In other words, the TriggeredSendCustomerKey and TriggeredSendDefinitionObjectID persist over the lifetime of the Triggered Send to identify that Triggered Send.
During the lifetime of a Triggered Send, the associated email content can undergo updates or refreshes. This means you can change the email creative, subject line, or other aspect of the email message, or even choosing an entirely different email asset while keeping the same Triggered Send active. Thus, it is possible that a single Triggered Send can be linked to many different Content Builder assets / emails (EmailID) throughout its lifetime.
Each time a Triggered Send is published or republished (regardless if any actual updates took place), a new job is generated with a unique JobID.
If you have edited an email in a running journey, after clicking ‘Done’, a saving window will initiate. This counts as republishing the Triggered Send and the email activity will have a new JobID.
When a republish occurs, the TriggeredSendCustomerKey persists, while the JobID linked to that TriggeredSendCustomerKey gets updated. This behaviour is what allows a single Triggered Send (that exists over time) to be associated with various emails (and various jobIDs). When we want to update email content within an active Triggered Send, we need republish the TS in order to apply the changes.
When significant changes are made during the re-publishing of a Triggered Send, you should communicate to stakeholders and document the why, when, where and what. This will empower you when it comes to reporting time and you’re trying to interpret the results, you’ll be armed with the business context.
Email Studio Tracking and Triggered Sends in Marketing Cloud
In the Email Studio Tracking screenshot, you might notice the use of the External Key instead of the Job ID. This indicates that the metrics shown in the Tracking section dashboard are for the overall Triggered Send, not breaking down the metrics for individual jobs associated with that Triggered Send. The same applies to the Triggered Sends Tracking Report in Analytics Builder, which groups results by the TriggeredSendCustomerKey.
Recommended by LinkedIn
When updating an existing email in a Triggered Send and republishing it:
- The TriggeredSendCustomerKey remains the same.
- The JobID changes.
- The EmailID remains the same since the email content was only edited, not changed.
To report on specific emails sent within a Triggered Send, focus on the associated JobIDs, which reference the specific email content delivered. You can extract the EmailID once you have the JobID.
A single Triggered Send can be linked to many EmailIDs, and updating it over time will generate new JobIDs. Each JobID defines the selected email and other send settings. Thus, when different EmailIDs correspond to the same TriggeredSendCustomerKey, there will also be new JobIDs.
For example, when refreshing content in an ongoing journey, such as updating Welcome Series emails with seasonal content, a new JobID will be created for each update.
DataViews Retention Policy:
- DataViews, including _JOB DataView, have a six-month retention policy.
- The retention calculation for Job DVs is based on the ModifiedDate field, while engagement DVs like Sent, Open, Click, and Unsubscribe are based on the EventDate.
- If a Triggered Send's ModifiedDate is older than six months, it will not be present in the _JOB DataView results.
For long-running journeys that haven't been modified in a while but are still sending emails, reporting queries involving joins to _JOB may produce incorrect results. If the job is no longer in the DataView, Sent, Open, and Click events won't be joined, causing these rows to be omitted from your results.
SQL Query Considerations:
- Avoid using INNER JOIN to combine engagement DataViews. For example, if an email sent in February is clicked in September, the sent event may have expired, causing the click event to be omitted from your reporting.
- Explicit date range limitations in SQL queries might exclude relevant events if the sent event falls outside the date range while the open event is within it.
Since you can republish a Triggered Send multiple times, be aware that while a certain JobID may no longer be active in sending new emails, emails already sent under that JobID will continue to generate engagement data.
Handling Unsubscribe and Complaint DataViews:
- Unsubscribe and Complaint DataViews do not have Triggered Send fields like TriggererSendDefinitionObjectID and TriggeredSendCustomerKey, which are present in Job, Sent, Open, Click, and Bounce system tables.
- This can complicate capturing these events in aggregate reports, especially if the unsubscribe originated from an email sent over six months ago and the Triggered Send hasn't been modified for a year.
To fill this gap, set up a DataView logging automation that logs all jobs to a data extension. Alternatively, use the messaging/v1/sends/instance REST API endpoint to retrieve email sends and associated JobIDs. A logging automation for this API object can help fill in missing TriggeredSendCustomerKey values for the Unsubscribe and Complaint DataViews. Logging queries are simpler than querying the REST API, which requires managing Auth tokens.
Final Recap:
- Primary Keys for Triggered Sends: TriggeredSendCustomerKey and TriggeredSendDefinitionObjectID.
- Triggered Sends differ from regular user-initiated sends.
- Journey Builder creates Triggered Sends behind the scenes.
- Triggered Sends exist over time.
- A new JobID is created when a Triggered Send is republished.
- Document and communicate Triggered Send republishing to help with future report interpretation.
- Older JobIDs continue to produce engagement data alongside currently active JobIDs.
- Avoid INNER JOIN in SQL queries related to Triggered Sends to prevent data omission.
- Double-check DataView SQL to ensure no accidental data exclusion.
The broader SFMC community has provided extensive documentation on setting up and using Triggered Sends. There are numerous detailed guides available that cover this topic comprehensively. For more information, see:
Salesforce Marketing Cloud Architect | Automation Expert | CRM Manager | Developer | Blogger | Marketing Champion 2020-24 🏆
4moDilip Sharma I couldn’t help but notice that the entirety of this content is strikingly similar - nearly word for word - to work I’ve previously published. While I’m glad it resonates with you, I kindly request that proper attribution is given to the original source to ensure respect for intellectual property and professional integrity. If you have additional insights or ideas to contribute, I’d be happy to collaborate and even update my original article to reflect them