FreeMarker: Restrictions

 << If/Else Statements Understanding Basic Render Errors >>

Here are some restrictions to keep in mind when using FreeMarker code to dynamically reference CRM fields:

Test Emails

Most FreeMarker code will not populate in an email that’s been sent via the Test button.  This is normal.  This is because there is no specific recipient (Account, Contact or Lead) associated with the test email that is sent (clicks and opens are not tracked either on Test emails for this reason).  ClickDimensions processes emails sent using the Test button in a different way than emails sent using the Send button or by another means of executing an Email Send, read more about Test emails here.

Test Email Button

Relationships

FreeMarker can only pull data from the recipient’s Lead/Contact/Account record and from records of entities that this Lead/Contact/Account has an N:1 relationship with.

You can think of it this way: if the recipient’s Lead/Contact/Account record can have more than one related record of a given entity (a 1:N or N:N relationship), the FreeMarker has no way to determine which of those potentially multiple related records to pull from.

FreeMarker can only reach one level beyond the recipient’s Lead/Contact/Account record.

For example, you can pull data from the recipient’s Contact’s related Owning User record, but you cannot go further and pull from a record that is related to this Owning User.

FreeMarker cannot pull from multiple lookup fields that reference the same entity within a single template, even if the lookup fields point to different records.

For example, you can pull from the recipient’s Lead/Contact/Account record’s Owning User record, but you could not in the same template pull from another different User record that is also related to that Lead/Contact/Account.

Making Child Record Data Accessible to Dynamic Content

As mentioned above, data from child records that the recipient Lead/Contact/Account record has a 1:N or N:N relationship with cannot be directly accessed via Freemarker, but there is a workaround (described here) that allows for that data to be referenced. The basic idea is to use custom fields and workflows to take data from the FreeMarker-inaccessible child records and place this data onto a FreeMarker-accessible Lead/Contact/Account record.

For example, create two custom “Upcoming Appointment” fields on the Contact entity and then set up a workflow that runs on the creation of an Appointment record and updates the associated Contact’s “Upcoming Appointment 1” or “Upcoming Appointment 2” field as appropriate. Once this is set up, you can pull data from the Contact’s “Upcoming Appointment” fields just like you would any other field on the Contact record.

Look-up Fields

Lookup fields cannot be referenced directly via Freemarker. Rather, the relevant field on the record being accessed via the lookup field must be referenced.

This is the incorrect syntax to reference data in a lookup field; the lookup field is being referenced directly: ${Recipient.contact.parentcustomerid[0]!””}

This is the correct syntax to reference data in a lookup field; the account name field on the account linked via the lookup field is being referenced:  ${Recipient.contact.parentcustomerid.account.name[0]!””}

A simple way to understand this limitation is to think of the Lookup field as a window. When you want to see something outside of your house, you look through the window, not at the window itself. For a more in depth discussion on Freemarker syntax, click here.


Feature Added: Original
Feature Updated: 6.7.0
ClickDimensions Version Need: 6.7.0
 << If/Else Statements Understanding Basic Render Errors >>