Important notice to all using custom objects in emails (bug confirmed by support)

Discussion created by 245570912a6411ea74ab8204fa94c8d1513e2e10 on Sep 21, 2016
Latest reply on Dec 29, 2016 by sanford.whiteman

Hi guys


I just found a huge bug yesterday that was just confirmed by support, and I want to share it with you all. It's especially relevant for you, if you're referring to custom objects fields in emails through email script tokens.


The array of objects in the object list is defined in the documentation as follows:

"For each custom object, the 10 most recently updated records per person/contact are available at runtime and are ordered from latest updated(at 0) to oldest updated(at 9)."


This makes a lot of sense. The latest updated object will always be number 0, so you can safely refer to that in the email script token, when you need data from a custom object to be inserted into an email. E.g. ${car_cList.get(0).model}.


I experienced some errors in my tests for a client, and I found out (which support has just confirmed) that the list of custom objects are not ordered from most latest updated custom object to oldest updated project, but is instead ordered by oldest created object to latest created object!!


This means that my tokens referring to ${car_cList.get(0).model}, is not pulling the model of the most recently updated car object, but is inserting the oldest created car object.


Let's say I have the following three cars connected to a lead:

CarA | Sedan | updated at September 1, 2016 | created at April 1, 2016

CarB | StationCar | updated at September 15, 2016 | created at March 1, 2016

CarC | Convertible | updated at September 21, 2016 | created at September 16, 2016


CarC is the latest updated. I want to send an email to the lead with the car data of the latest updated car. Following documentation you would identify the object using car_cList.get(0). However, this actually returns the data of the oldest created car, which is CarB!


This is a HUGE problem. It completely removes the "simple" use of email script tokens to input fields from a custom object into an email. Marketo engineering is working on it, but we can only expect the bug to be fixed by the winter release, which I believe is completely unacceptable.


I'm currently investigating whether the same issue exists for referring to the opportunity object in email script tokens, but if it does, you might be able to bypass it using ${TriggerObject.ProductName}, if the email is send through a smart campaign triggered by a change/creation of an opportunity. Unfortunately you can't trigger on custom object changes (yet), so we can't use that for solving the issue for custom objects.


I'm writing on a piece of velocity script that (hopefully) can run through all custom objects, order them by updatedAt and through that identify the latest updated object to pull field data from. It will only work if there's 10 or less objects (since the list of objects contains a maximum of 10 objects - if it was ordered by the 10 latest updated objects that was acceptable - now it's not). I'll post it here, when I'm done.


Have any of you guys experienced the same? Josh Hill Grégoire Michel Dory Viscogliosi?