Requested Bug Fix: In HTML Emails, Do Not Strip CRLF Characters Out When Inserting Text Fields Via Tokens

Requested Bug Fix: In HTML Emails, Do Not Strip CRLF Characters Out When Inserting Text Fields Via Tokens

I have filed a bug for this issue, and the response from Marketo Support was to post this as an issue here.

 

Background: Both Salesforce and Marketo allow carriage return/line feed (CRLF characters) in text fields. In SFDC, for example, users can type sentences, hit the Return key, and thus format entries into paragraphs. When this field syncs to Marketo, Marketo also displays the text with line breaks in its UI for the person record. When you import text with CRLF characters into Marketo, the CRLFs are also preserved. @SanfordWhiteman also has a famous workaround for inserting CRLF characters in tokens.

 

Issue: When the same field is inserted into a Marketo HTML email using a field token, Marketo strips out the CRLF characters when it inserts the contents of the field. Thus, a field that was a series of paragraphs in SFDC and Marketo turns into a single paragraph in an HTML email, often making it unreadable.

 

Why This is a Problem: If the CRLF character was included, you can use a Velocity script to replace the CRLF character with a <br/> HTML code so that the line breaks appear in the HTML email just as they appear in the Salesforce and Marketo UIs.

 

Do Not Be Confused! It is true that browsers and HTML email readers will ignore CLRF characters. That's OK. Let them continue to do so ... there is thus no harm in including CRLF characters. But by stripping them out, the Marketo email editor has disabled a very essential usability fix using Velocity.

 

I have spoken with Marketo developers such as @SanfordWhiteman and it seems that CRLF characters appeared previously, allowing this usability enhancement via Velocity.

 

I have verified this in HTML email but also assume it would apply to HTML output in LPs.

 

Please restore the CRLF characters to the token output in HTML.

1 Comment
Casey_Grimes
Level 10

1. Absolutely agree to everything you've written

2. While we're on the topic of CRLF, I would really love a better way of handling CRLF on textarea outputs via API—right now, any bulk extracts involving the characters forces line breaks in output. Given that Marketo already uses "null" as a string to interpret as a null, could we please get the ability to just use some type of psuedostring for export/import? I'm thinking of turning a field from

"123 A St

Suite 100"

to something like "123 A St\\r\\nSuite100", so the field can be successfully exported and then correctly parsed upon re-import to be the proper CRLF characters. This issue more commonly affects textarea fields not using hacks or workarounds, but coming from the CRM.