3

I am using Salesforce triggered send to send emails via Marketing Cloud. If I use a vanilla email (without any personalisation) the triggered send in Salesforce activates fine and works as expected.

However if I add the context data (recordId and sObject) as found in their documentation, the activation fails. As soon as I remove those references the trigger activates as expected.

Here is what my text email contains:

%%[
Set @mySObject = SObject
Set @myRecordId = RecordId
]%% 
<br><br>
SObject From API Call: %%=v(@mySObject)=%% <br>
RecordId From API Call: %%=v(@myRecordId)=%% <br>

EDIT: I have enabled error logging and found the the publication of the triggered send returned a failure with error code: 30000.

Second Edit: Looking at the REST error code page it appears this is a generic error with a description of "Ensure you provide the correct resource.", which means nothing to me.

2
  • 1
    Have you verified SObject and RecordId are passed in every call? If they do not exist, then SFMC will throw an error because you are referencing a field that does not exist. If you need to allow this for records that may not contain this field, I would recommend using AttributeValue("SObject") instead as this will just return null if the field does not exist, not throw an error. Commented Nov 27, 2019 at 18:07
  • I don't get why these would ever be empty though? These are what at the minimum will be sent via the Salesforce trigger. I have switched it to AttributeValue() and it is now working. Please add this as an answer. Commented Nov 27, 2019 at 19:26

2 Answers 2

1

(Added as an answer from my comment as requested by @DeploymentFailure)

Have you verified SObject and RecordId are passed in every call?

If they do not exist, then SFMC will throw an error because you are referencing a field that does not exist.

As to why they wouldn't exist, it could be that your API call is culling all null or empty properties/fields prior to sending it out. Essentially making it so if that is null, it is not sent over. usually this is a good thing as it lowers the amount of unnecessary data passed, but in edge cases like this, it can cause issues.

If you need to allow this for records that may not contain this field, I would recommend using AttributeValue("SObject") instead as this will just return null if the field does not exist, not throw an error.

This is why I usually recommend putting all personalization string calls in via AttributeValue(). You can then utilize RaiseError() on that if you need error handling to gracefully fail the email if it doesn't meet your criteria.

I believe that even if you have these fields in a Triggered Data Extension, it will still error the email if they are not included in the call as the Triggered Send utilizes the information passed in the call, not the data extension for the Send Time data. The TDE is really just there as a reference/log for what data was passed, and is separate from the actual send process - which can be seen when the data is pushed to the DE, but the send fails. If they were tied together and not asynchronous, then the data would not be entered into the DE if the send failed.

3

Use this instead:

<br><br>
SObject From API Call: 
%%=v(AttributeValue(“mySObject"))=%% <br>
RecordId From API Call: 
%%=v(AttributeValue(“myRecordId"))=%% <br>

The way you did it would work only if you had a Triggered Data Extension tied to this Triggered Interaction, and your TDE had columns for “mySObject” and “myRedordId”.

See here, in the “Personalizing triggered emails” section: Introduction to Triggered Sends

You must log in to answer this question.

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