“Hope for the best and prepare for the worst” should be every marketer’s motto when it comes to creating contextual personalized content. Your company’s reputation could be easily tarnished if you send out buggy emails, that’s why exception handling should be an essential element of your email strategy.

In this article, you will learn about some of Salesforce Marketing Cloud’s build-in features and best practices that will help you maintain high quality of content that goes out to your subscribers.

Fallback values in emails

When it comes to creating personalized emails, we often hear Salesforce Marketing Cloud users assume that the data that comes through will be correct and that they are not going to include fallback values for their variables. The assumption should be exactly the opposite and you should always plan for bad or missing data!

If you’re using a Profile Attribute or a Data Extension column for personalizing an email, the best practice is to always leverage the Empty() AMPscript function to check whether there is a value available.

Here’s an example: it’s much easier to use a simple personalization string such as Dear %%FirstName%%, in your email, but if for some reason the data is missing, your subscriber would see Dear , in the email they receive. This can be easily prevented by using the Empty() function and adding a fallback value: [see code snippet]

	%%[
	set @firstName = AttributeValue("FirstName")
	if empty(@firstName) then
	set @greeting = "Valued Customer"
	else
	set @greeting = @firstName
	endif
	]%%
	<p>Dear %%=v(@greeting)=%%,</p>

view raw email-personalization-fallback.html hosted with ❤ by GitHub

In the above example, a Profile Attribute or a Data Extension column will be used if there’s a value available, and if not, the greeting in the email will be set to Dear Valued Customer.

Whether you’re using Lists or Data Extensions to segment the data in Salesforce Marketing Cloud, you can also leverage the “Default Value” feature to ensure that required data is always available:

Using the RaiseError function in emails

The RaiseError() function, used along with a conditional statement, ensures that the email does not get sent if there is bad or missing data in the dataset used for personalizing the email. Depending on how you set the function, it can either skip the send for a current subscriber and move on to next subscriber, or it can stop the remaining send job. Here’s a summary of the function’s main features in Eliot Harper’s video:

Let’s take a look at the function syntax and properties:

RaiseError(1, 2, 3, 4, 5)

Ordinal	Type	Required	Description
1	string	N	Error message to display
2	boolean	Y	Indicates whether function skips send for current subscriber and continues or stops. A value of true skips the send for current subscriber and moves to next subscriber. A value of false stops the send and returns an error. Function defaults to false.
3	string	N	API error code (set by the user)
4	string	N	API error number (set by the user)
5	boolean	N	Indicates whether the function records information to data extensions before error occurs, even if the process skips the subscriber. A value of 1 retains information written to data extensions before the error occurs, even if the subscriber is skipped. A value of 0 does not retain information recorded before the error. This parameter refers to inserted, updated, upserted, or deleted information via AMPscript.

Let’s use the previous script example with the FirstName personalization, but instead of setting a fallback value in case the FirstName is missing, we will use the RaiseError() function to skip the send for that particular subscriber: [see code snippet]

	%%[
	set @firstName = AttributeValue("FirstName")
	if empty(@firstName) then
	RaiseError("First name missing", true)
	else
	set @greeting = @firstName
	endif
	]%%
	<p>Dear %%=v(@greeting)=%%,</p>

view raw email-personalization-raiseerror.html hosted with ❤ by GitHub

You will notice, that upon previewing the email, the error message that you set will be displayed if the FirstName value is missing:

In a scenario where you would try to send this email to a subscriber with a missing FirstName value, the function would prevent from sending an email to the current subscriber and would move on to the next one.

This function should not be misused for data segmentation. Even though a subscriber is skipped or the whole job is cancelled, it still counts towards your totals as a sent message, meaning that you will pay for each suppressed email as you would for a sent one. This is a small price to pay for handling exceptions and sustaining a positive reputation with your subscribers, but it should not replace regular data cleansing and maintenance processes.

An additional thing to keep in mind is that AMPscript is interpreted top-down. This means, that if there are any other AMPscript functions before the RaiseError() function, they will all be executed, even if the send for a particular subscriber is skipped in the end.

On the other hand, if you have set the RaiseError() function to cancel the remaining send job, then any Update, Insert, and Delete AMPscript functions, which are processed in bulk during send time, will not be executed, unless you specify otherwise by setting the last of the RaiseError() properties to 1.

Bear in mind, that the second property of the RaiseError() function, which indicates whether function skips send for the current subscriber and continues or stops, will default to false if not specified. This means, that unless set to true, it will always stop the remaining send job.

Logging RaiseError results

By default, the emails and jobs suppressed by the RaiseError() function will only be visible in the NotSent tracking extract. If you’re using this function in Journey Builder emails or Triggered Sends, you will also be able to see how many emails were suppressed by checking the “Errored” column in Email Studio’s Tracking tab, under Journey Builder Sends/Triggered Sends. Unfortunately, you won’t be able to view any details of the suppressed sends in the UI.

In order to log all suppressed sends, you can create a Data Extension and add an InsertDE function to the email. Make sure to set the last property of the RaiseError() function to 1 and to include the InsertDE() function before the RaiseError() function, as everything placed after won’t get executed. This way, each email suppressed by the RaiseError() function, will also be logged in the Data Extension: [see code snippet]

	%%[
	set @firstName = AttributeValue("FirstName")
	if empty(@firstName) then
	InsertDE("RaiseErrorLog", "JobID", jobid, "EmailName", emailname_, "SubscriberKey", _subscriberkey, "EmailAddress", emailaddr)
	RaiseError("Missing first name", true, 1)
	else
	set @greeting = @firstName
	endif
	]%%
	<p>Dear %%=v(@greeting)=%%,</p>

view raw email-raiseerror-logging-insertde.html hosted with ❤ by GitHub

Analyzing the log will help you investigate why some of the values are missing and improve your company’s data hygiene.

---

Questions? Comments?

Leave a comment below or email me at zuzanna@sfmarketing.cloud.

---