The dot is regular expression syntax for "any character," so the idea was to see what you saw.
Now try this:
${lead.Lead_Notes.replaceAll("\r","<BR>")}
That did not work:
Which is what's really bizarre since I tried three different types of line-breaks in my tests:
Just for the heck of it, I tried ${lead.Lead_Notes.replaceAll("e","<BR>")} and got this:
So the issue is clearly with the hidden line-break character.
Yeah, the question is what on Earth could that character be in your instance?
The {{token}} expressly contains a single \n.
We've now tried Velocity replacement expressions on \r\n, \n, and just \r!
Try this and post the output:
#foreach( $char in $lead.Lead_Notes.toCharArray() )
$lead.Lead_Notes.codePointAt($math.sub($velocityCount,1))<br>
#end
Here's the output:
108
105
110
101
49
32
108
105
110
101
50
32
108
105
110
101
51
That shows that the newlines are spaces (char 32) in your Velocity context! What the?!?
And yet the newlines are preserved in the UI when you refresh the page?
You mean here? If so, then yes. These were all entered as:
line1<ENTER>
line2<ENTER>
line3
Maybe we should get on a call and figure this out. Send me an email...
Sandy, thanks for taken the call with me yesterday. I went ahead and cloned the working alert email that gets sent as part of a trigger campaign. That email failed to render as well. The commonality in all of this testing is that it seems to work with trigger campaigns, but not batch campaigns (all my tests were done using batch campaigns). Are you aware of any limitations in using specific velocity methods with batch campaigns (similar to how you cannot use tokens in the "send alert" flow step as I mentioned here: Sales Alert Batch Campaign ?
No man, that's crazy. Esp. because it's the field value itself that seems to be getting munged in the batch campaign and not getting changed in the trigger.
That very well may be the case as well. But how do we get Support to determine if that's what's happening?