Hello all,
as the title says, I need help with a velocity script I'm planning to use on a campaign to be sent out in the next days. Let me start by saying that I am not a developer, so the extent of my ability with Velocity is quite limited...
The velocity script simply shows a list of names and dates in a table-like format, but I've come across a couple of obstacles:
1. the date format seems to be the "american" one (mm-dd-yyyy), however it would be best if it showed in the "european" format (dd-mm-yyyy). A workaround I found to avoid adding more code to the script is to have the "Date" field on the custom object as a string instead of a date, but I fear that doing so might hinder or limit some features related to smart campaign operators.
2. this is the most important: is there a way to limit the number of records appearing on the email to just those that are added each time? For example, if I use the "Added to custom object" trigger to send an email to a lead that already has 4 records in his custom object, adding 2 new records to it, my goal would be for the email to show only the 2 new records added, but it instead shows all 6 records.
This is the code (very simple) that I am using:
<table>
<tr>
<td>Name</td>
<td> </td>
<td>End date</td>
</tr>
#foreach ($CustomObject_c in $CustomObject_cList)
<tr>
<td>${CustomObject_c.lastName} ${CustomObject_c.name}</td>
<td> </td>
<td>${CustomObject_cList.endDate}</td>
</tr>
#end
</table>
What can I do?
Thanks,
Francesco
Solved! Go to Solution.
Can't solve race conditions with a wait step (and this one is related to the SFDC sync interval). Tons of Marketo integrations are broken because people didn't think about synchronization and concurrency. But let's leave that aside for now.
Given the broad interval between uploads and the other assumptions you're making, I think you're actually overengineering your design. Why not just tag the COs with a timestamp and only process the ones from the previous day? After all, your second upload to flip the bit is assuming they're done without doing any further checking.
Hello Sanford,
thanks for the insight. With "singular" you mean that if I use ${TriggerObject} I am limited to show just one record, even if in a data upload I uploaded two or more record for a single lead at the same time?
Yes, although actually "the same time" isn't the way it's processed (the inserts are always in a sequence).
What you probably want to do, now that I think about it, is maintain a log field (custom textarea field) where you append the IDs of the objects you processed in each go-round. Then pass this field into Velocity and only use those members of the CustomObject__cList that haven't already been logged in the field.
What if I define a field in the custom object (e.g. a boolean) that handles whether the specific record has already been uploaded, and build the script so that it checks for that field and only displays the records that have a certain value? I'm throwing this out there as an idea, not sure if possible.
As of today all data imports are made through lists uplodaded directly into Marketo as we are still in the "building" phase, but I can envision this object being synced to SFDC in the future, so if my approach above is feasible it could be even more simple to maintain via a workflow that updates the field under certain conditions (i.e. after some time has passed).
Surely I'll need to get access to someone experienced in Velocity/Java, but at least this conversation can help me understand if I am on the right track or not
Thanks!
What if I define a field in the custom object (e.g. a boolean) that handles whether the specific record has already been uploaded, and build the script so that it checks for that field and only displays the records that have a certain value? I'm throwing this out there as an idea, not sure if possible.
You couldn't flip that boolean in Velocity (that is, Velocity can't mark an object as done). You could change it in SFDC if you use an SFDC custom object, but that's going to create a clear race condition because you've said you'll be adding muiltiple records in the same batch upload.
What I meant was that I essentially intend to make each upload twice, once for the actual upload of records and a second time for the update of the boolean field. I'm aware of the race condition, but these actions don't necessarily need to be made in real time so it's possible to have a "Wait" step in there to handle the race.
Also, I know this might not be the best approach but until the sync with SFDC is done my options are limited... Consider that we will have roughly one upload a month, so we have plenty of time to add wait steps that can manage the race.
In my mind, the campaign could look something like this:
Trigger - Added to Custom Object
Filter - Member of list (this is to help narrow down the leads to exactly the ones we need)
Flow
Schedule - Each lead can run through the campaign every 2 weeks or so (this is to give a buffer time where we can re-upload the file to update the boolean without triggering the SC a second time)
Does this make sense?
Can't solve race conditions with a wait step (and this one is related to the SFDC sync interval). Tons of Marketo integrations are broken because people didn't think about synchronization and concurrency. But let's leave that aside for now.
Given the broad interval between uploads and the other assumptions you're making, I think you're actually overengineering your design. Why not just tag the COs with a timestamp and only process the ones from the previous day? After all, your second upload to flip the bit is assuming they're done without doing any further checking.
I think you hit the nail on the head! Basically you're saying I skip the boolean field (and related update) altogether and only have a timestamp field (or use the Created At/Updated At) to reference in the script that only gets the records with a value of one day before, correct?
I still would need access to an experienced developer to write the code, but if the syntax allows it then I think this could be the easiest way to handle it.
Thanks!
Yep, very easily done in VTL. I wrote a bit recently about people forgetting to convert timezones -- but with that covered, very simple!