Cleaning up company name using velocity script

[Broderick_Klem1]

I have company name pushing in Marketo from Salesforce, but it's the legal name, meaning that it includes things like "LLC" or "Inc". I'm trying to build a custom token to clean it up (similar to what I do with first name), but I'm a little lost in the syntax. How do you remove a portion of a string? So for example, if I have "Amco General LLC", how do I end up with "Amco General"? Thanks!

This is what I've got so far:

#set( $Company = $lead.salesforceAccountName.trim() )
#set( $CleanCompany = $lead.Clean_Company_Name__c.trim() )
#if( $CleanCompany.isEmpty() )
#if(
$Company.isEmpty() ||
)
your company##
#ifelse(
$Company.matches("LLC") ||
)
[something that removes the LLC (and space before it) from the company name]
#else
$Company##
#end
#else
$CleanCompany##
#end

[SanfordWhiteman · Accepted solution]

#set( $Company = $lead.salesforceAccountName )
#set( $CleanCompany = $Company.trim().replaceAll("(?i),?\s+(LLC|INC\.?)${esc.d}", "") )
${CleanCompany}‍‍‍‍‍‍

Knowing every possible "extra" automatically isn't going to happen, but this strips the low-hanging suffixes LLC and Inc..

Do try to highlight your code for real using the Syntax Highlighter (you can choose Java as the language, it's close enough to Velocity). I find it very hard to read otherwise.

[Broderick_Klem1]

Thanks for the help Sanford, this is fantastic! I'll make sure to use the syntax highlighter next time, I didn't realize there was one.

[SanfordWhiteman]

Broderick please check the thread for updates.

[Jep_Castelein2]

As an alternative, consider adding a "clean Account name" custom field in SFDC, which is populated with a Workflow or Custom Trigger, then syncs to Marketo. Velocity scripting will cause your email to take at least 3 times longer to go out. Not a problem with 10k records, but starts being noticeable if you email more than 100K people. 

Calculating in SFDC is just a one-time computation and a one-time sync to Marketo. After that, it only has to be updated when the Account Name changes (which should be rarely). 

[SanfordWhiteman]

Velocity scripting will cause your email to take at least 3 times longer to go out.

It's not 3x, Jep. Any such penalty is extremely minor -- when it exists at all in practice.

Remember that the assembly process parses Velocity even if you don't explicitly include any Email Script {{my.tokens}}. It's not like you avoid instantiating the Velocity context.

We've done extensive benchmarking on this, and the TTFD (Time To First Delivery) and delivery spread (TTLD  - TTFD) is effectively identical for an email asset with no tokens at all vs. an email with simple Velocity logic applied to a single field, like the above. Underlying differences in assembly time end up blending into the background noise.

With in-depth testing, you'll see that 10,000 emails with a simple Velocity token may assemble, queue, send, and be 100% delivered in less than the time it takes 10,000 empty emails to even start to go out from the same instance.  Depends on what else is going on at the time. 100,000 emails with Velocity can be faster, slower, or effectively the same as 100,000 non-Velocity emails.

Of course you can do a wide range of things with Velocity. On the low end, you might just output static text. On the high end, you can inject lots of lead and CO properties into the context (naturally requiring more RAM) and perform sorts, filters, date math, object casts, et al. Those high-end features can add milliseconds or even full seconds onto the elapsed time, and eventually there is an effect with large sends, but using Velocity at all is not the worry.

I agree it would be best to save this particular "cleaned up" field permanently rather than regenerating it every time, since it's a very slowly-moving data point. You could create the permanent field via webhook or via SFDC. Even though the Velocity overhead is negligible, the permanent field can be used in other places that don't support Velocity, like Landing Pages, SMS, etc.