Marketing Cloud — End to End Triggered Email Overview

Marketing Cloud users can test most of the core functionality within the platform and via the connector into Sales Cloud. Users can create a Salesforce Journey and send a test email, create or update an object such as a lead in Sales Cloud, update a data extension that kicks off another journey, and much more. Users can even create an automation to query other data sources, populating a data extension and seeing the results within minutes.

However, triggered emails sends don’t have that native end-to-end functionality built into Marketing Cloud. The user can build the content, the triggered data extension, and the triggered send, but there’s no built-in functionality to trigger that send outside of using scripting in a Cloud Page or in Automation Studio. That’s because triggers are typically fired through an API call to the triggered send definition external key. In most cases, a third-party platform sets up the API connection through an installed package in Marketing Cloud.

In this post, we offer a simple solution for using a free API provider called Postman, which gives you the ability to send triggered emails in just a few minutes.

Let’s start with the basics of how to set up a triggered send in Marketing Cloud and then jump into a quick walkthrough of Postman.

Setting up a triggered send

A triggered send in Marketing Cloud is made of the following parts:

- Content: the email that will be sent

- Triggered data extension: a specific type of data extension

- Triggered send definition: the instructions that pull the event together and provide a key for the API call

- Installed package: the settings that allow an API call to trigger the send

Content

There isn’t anything technically specific to triggered sends that you need to keep in mind when you are building the content, but here’s a few tips to help make the testing and “go live” process run a little smoother:

1. Create a test send data extension with complete data. Before you build your content, set up your triggered data extension and populate it with test data that will be used in the test send. If you are personalizing your content — for example, if there’s a field in the data extension labeled FirstName and you have %%First_Name%% in the body of the content — then test this functionality with actual data. If you are using a custom from name and email address tied to a custom send profile, test this functionality as a regular send.

2. Test, test, test. Test your triggered content like you would regular email content. Use the preview/test functionality when editing the content, sending a test send with the triggered data extension as the source. Send the content as a regular or user-initiated send with a regular test data extension. Here’s why: if there are any errors related to the content, the triggered send will error out, and the documentation about those errors within the triggered send functionality is limited. If your content works effectively as a regular send, you’ll prevent errors. And if errors do pop up, you’ll know it’s not related to the content.

3. Separate triggered send content from other sends. Separate triggered send content from blast, automation, or Journey content. Create a separate folder, and document the content, data extension, and triggered definition settings. This will help prevent any unintended changes to the content after going live, which might cause the trigger to fail.

Triggered data extension

Select a new standard data extension. Under Creation Method at step #1, select the Create from Template option in the drop-down menu.

Select “TriggeredSendDataExtension” as the template.

This template sets the subscriber key and email address as the first two fields and sets the data extension as send-able. The rest of the setup is exactly like any other data extension.

Triggered send definition

Under the Interaction tab in Email Studio, select Triggered Sends. Create the appropriate folder, and then create a new triggered send. Setup can seem very straightforward as the definition walks the user through all the necessary information needed from the external key to the content to the data extension. We’ve highlighted a few helpful tips to avoid common pitfalls that can cause problems in testing or, much worse, can send emails that don’t honor the unsubscribe settings.

1. Set an external key that is unique but not too long. This key is the unique identify for the API call to send the trigger, which we discuss more later in our Postman walkthrough. Avoid extra-long keys, especially with spaces, to prevent errors when testing for going live.

2. Use this setting if you want to use a custom send profile. Don’t forget to make sure the API call does not include “from” settings as it will override the sender profile you’ve selected here.

1. Simply select the content to be used as the trigger in its own triggered send folder. Try to avoid sharing the content with other efforts. Your triggered content should only be used for one purpose.

2. The subject line will appear automatically. It can be edited, but best practice is to modify this in the actual content.

3. Select the triggered send data extension, which is stored in a separate triggered send folder.

4. Triggered Send Managed List: This is an often-overlooked, confusing, and dangerous part of the trigger setup. Under the list box, select a list — most likely All Subscribers, which will be used to verify the subscription status of each send. There is no checkbox to confirm the selection — only what is depicted above as the selected list becomes greyed out.

If the user doesn’t select All Subscribers or another list, the system will default and use what Marketing Cloud describes as the Triggered Send Managed List, a hidden system-defined list to verify status, which doesn’t support all triggered send-based functionality. There’s limited documentation on this hidden list, but what’s more surprising is that Marketing Cloud sets it as the default. Doing some digging in the back end, this list has a subscriber type of Unknown External System and can be queried by selecting subscriber type != ‘ExactTarget.’

What Salesforce fails to mention is that this Triggered Send Managed List won’t honor the unsubscribe settings in All Subscribers. We’ve encountered use cases where an unsubscribed customer became irate because they continued to receive emails — all because a triggered send wasn’t set up properly to verify against the All Subscribers list. Take the time to follow the steps and document each trigger setup as these small details can have a large impact in the end.

Installed package

In setup under Platform Tools and under Apps, you’ll find the INSTALLED PACKAGES. Select New, and enter a name and an API integration component from the check list.

Select Server-to-Server as you’ll need both a Client ID and Secret for the API call plus client credentials.

In the Properties section, a triggered send only requires a few properties to be selected.

Once all the properties are selected, the Installed Package will be created with the Client ID and Secret plus the Auth and REST Base URIs. This information will be used in the next session: the Postman API setup.

Postman walkthrough

Postman is a free third-party tool that allows users to send test API calls. Download the app at postman.com, and set up a workspace to create your collections. You might have a different collection for each triggered test or installed package.

Once your collection is set up, create two requests: Get Token and Send Trigger.

Get Token Request: This will send a call to the Auth Base URI with the Client ID and Secret to obtain a token to open the API connection.

1. Grab the Authorization Base URI from the installed package, and select POST as the default will be GET. After the Base URI, add /v2/token.

2. Select Raw to enter in the code listed below.

3. Select JSON in the drop-down menu.

4. Enter the Client ID and Secret from the installed package.

5. Click send, and if all goes well, you’ll receive an access_token.

Triggered send request: the request that will fire the triggered send

1. Select POST as the default will be GET.

2. Copy the REST Base URI from the installed package.

3. Copy the above URL syntax for a triggered send (available from Marketing Cloud documentation).

4. Enter in the external key for the triggered send definition. (Note: Marketing Cloud documentation does not specify adding the key: before the external key, but it is needed at least for Postman.

5. Select Raw to enter in the code listed below.

6. Select JSON in the drop-down menu.

7. Enter the email address in the Address and SubscriberKey.

8. Enter the data that needs to be passed to the Triggered Send Data Extension.

9. Click send.

One last thing: before clicking send, copy the access token from the Get Token Request, and paste it into the Authorization tab for the Trigger Request. Select Bearer Token type.

This should be the response returned showing the queued status.

And if you jump over to the Marketing Cloud side, you should see the following under the triggered send:

1. The trigger send will be queued like the status received in Postman.

2. The status of the trigger is Running, which is a common issue since triggers often need to be started to obtain a running status and accept API calls.

3. After creating the triggered send definition, don’t forget to click start in the trigger menu.

4. Errored will alert you when there is a problem with the send. The error messaging doesn’t tell you if it is the content, the data extension fields or the API call itself. This is why it’s always helpful to do a test send with a test data extension and content to work out those errors before the triggered send.

After a minute or two, the triggered send should be completed.

Check the Triggered Data Extension to verify that the data came through:

Hint: When creating the data extension, add a CreatedDate field, and set the default to the current date to populate the date when the trigger is sent. CreatedDate is a must for most data extensions to identify when the data was created.

And finally, the email should arrive in your inbox:

End-to-end testing with triggers is a relatively simple exercise that can provide significant benefits, including the following:

- Saves time: Identify errors and issues ahead of time, preventing sleuthing with errored triggered sends. You might discover an issue with the data that requires a content or data redesign.

- Saves money: Eliminate testing fees and developer implementation hours from your third-party provider.

- Generates complete documentation: Detail the setup from end to end for complete documentation, which will allow for easier troubleshooting down the road.

Pay attention to those triggers. They are an often overlooked, underutilized, and not consistently set up or managed tools in Marketing Cloud. However, we’ve seen them become some of the most effective ways to communicate with a target audience.

Check out Postman; it’s one of our favorite tools. If you do, check out environments and setting the URIs, the auth token, and other data points as variables. It’s a more advanced way of setting up the API calls and can save steps down the road.

At Cervello, we are passionate about not only Salesforce and Marketing Cloud, but also solutions to help our clients become smarter and more mature in their processes. Our approach is not to add overly complex solutions that are difficult to stand up and impossible to support. Instead, we develop the core skills that will build a solid foundation for your marketing automation team with efficient, mature, and supportable programs.

About Cervello, a Kearney company

Cervello, a Kearney company is a data and analytics consulting firm and part of Kearney, a leading management consulting firm. We help our leading clients win by offering unique expertise in data and analytics, and in the challenges associated with connecting data. We focus on performance management, customer and supplier relationships, and data monetization and products, serving functions from sales to finance. We are a Salesforce partner and help our clients implement, customize, and optimize the platform into the best solution for their needs.