Skip navigation
All Places > New York User Group > Blog > 2018 > March

Boolean type fields enjoy a strange place in Marketo's Velocity implementation.

On the Marketo UI side and via most Marketo APIs, Booleans hold consistent true/false values (presumably using SQL bit type fields under the hood).

But in Velocity, as I've explored before, a Boolean field is presented as one of two Strings:

  • "1" for Boolean true
  • "" (empty string) for Boolean false

That conversion is actually really confusing.

See, Velocity inherits a lot of things (variable handling things) from Java.

In Java, a non-null String object, on its own, is always evaluated as Boolean true. Regardless of whether it has any characters in it (that is, regardless of whether it's empty).

So if you do:

#if( $lead.someBooleanField )
Field is true
Field is false

You will always get “Field is true” even if you've unchecked the corresponding checkbox in the Marketo UI.

If Marketo Booleans were Velocity/Java Booleans, on the other hand, this would've worked fine. But alas.

So the question is what to do with these sort-of-Boolean-like-Strings (whose meaning we understand, but the VTL language doesn't). What do we convert them to to make them more usable?

You can do a step-by-step conversion to Boolean by doing a String comparison:

#if(  $lead.someBooleanField.equals("1") )
#set( $lead.someBooleanField == true )
#set( $lead.someBooleanField == false )

After that conversion, #if($field) will work as expected.

But I've been thinking lately that maybe converting those Strings to Numbers — 0for false and 1 for true, as the standard goes — gives us more juice within Velocity than if we were to go with true Booleans.



Read the full post on TEKNKL :: Blog →

GDPR and related regulations call for some fancy footwork with activity tracking.


Leads may be members of the same program, set to receive the same email but many have opted-out of tracking, while the rest agreed to be tracked for the greater good.

So you need a single email to go out, but some get the tracked version of links (bounced off your branding domain) while others get the raw links (straight to the URL). Same for the <img> that tracks opens: some get the pixel, others don't.

The solution, as for so many things, is Velocity.

If canBeTracked is your Boolean lead field, first convert it to a number:

#set( $link = "" )
#set( $canBeTracked = $convert.toNumber("0${lead.canBeTracked}") )

Then you can use this VTL logic to selectively track links:

#set( $trackingClass = "{0,choice,0#mktNoTrack|1#}" )
<a class="${display.message($trackingClass, $canBeTracked)}" 
   href="">Le Click, C'est Chic</a>

That'll output a tracked link for those that opted in, an untracked link for everyone else.

To selectively track opens, first disable open tracking in Email Settings:


Then manually include the open-tracking pixel in the template:

#set( $trackingLink = "${mktmail.QpMarketoId}" )
<img src="${display.message("{0,choice,0#|1#${trackingLink}}", $canBeTracked)}">


What's that $display.message() thing?

I've explained the code internals in a separate post to keep this one short!

     Velocity is the only language where Brevity for Brevity's Sake is OK.

     In other languages, reducing total lines of code (LOC) with show-offy shortcuts just means your code will make no sense (to you or anyone else) after a few months away.

     But in Velocity, the shortest possible implementation is a smart move, since:

    • VTL is verbose (only one major operation permitted per line, temp variables required even for void methods)
    • it offers limited reusability (especially Marketo's flavor of Velocity, where #macro and reused $references don't work consistently)
    • it's completely whitespace-preserving (indenting would help readability, but messes up output — so the fewer lines, the less to mess up)
    • the more lines of code in your template, the more distraction from the “meat,” which is the output

     Imagine you had a few Lead fields using the JETDS naming system: installationEnvironment, typeOfEquipment, and purpose.

     There are 10-20 options for each of these fields, so the number of total combinations is huge. Even if you're only interested in a subset, the conditions get loooooong...



Read the full post on TEKNKL :: Blog →

     This is more like a pre-Velocity tip, since you need to make this decision while setting up your Marketo and/or SFDC Custom Objects, before you even try to read them using Velocity.

     Neither SFDC nor Marketo will stop you from creating such COs, and Marketo will even show them in the script editor:


     But your Velocity scripts will always error out if you use those objects (with the unhelpful error message String index out of range -1).

     The reason?



Read the full post on TEKNKL :: Blog →

Y'all have seen this type of double-confirmation popup, I'm sure:


It's helpful if you want to give end users a little additional nudge, for example to use their legal name, a working email address, and so on — stuff that you can't force them to do but maybe can guilt them into.

No one but me would claim it's “easy” to add this functionality to a Marketo form. It only took an hour to whip it up, but as you know, I waste spend more time in Forms 2.0 API-land than anybody else. Lucky for you, I've provided a big leg up by linking to a working CodePen that you can spin off for your own site.



Read the full post on TEKNKL :: Blog →