The syntax for reference contact properties (which are the same as form fields in HubSpot) would be {{contact.property_internal_name}}. So for favorite color you might do something like {{contact.favorite_color}} to get that to appear in your email using HubL. Full documentation can be found here: http://designers.hubspot.com/docs

Problem is, if/else statements for contacts don’t work in emails. Per Hubspot’s note on this page:

Please note that using personalization variables (contact and company variables) within if statements is not currently supported for email in HubSpot. These variables can be used for logic on COS page and blog templates.

So I’m trying to find a different solution. Perhaps using the Forms API?

I’m not convinced the Forms API will help, unless you are willing to set up server-side infrastructure to act as a proxy and execute your field checking logic; the HubSpot Forms API is not CORs compliant (meaning that its generally unable to be utilised client-side).

I’ve faced similar use cases before, I solved this by building the required HTML snippet client side and inserting it into a hidden form field prior to form submission. I don’t know your level of programming proficiency, but this is how I went about it (posting here as I figure others can make use of this even if it is potentially too complex for you);

Create a custom contact property to store your HTML snippet, and include it in your form as a hidden field.

Either in the footer of the page or within a custom HTML module within the template, create a JS function containing the logic to build your HTML snippet; I built an ordered list using variables from the form, querying a JQuery object of all form inputs from the HS form other than the submit button, and inserting each input value where required.

Ensure that the function populates the hidden form field created prior. Remember to use .change(), eg: $('#hs-form-identifier input[name="field_name"]').val(html_snippet).change(); The last thing your function should do after inserting the HTML snippet into the hidden field is to submit using JQuery as we are preventing the submission above; $('#hs-form form').submit();

Set an action listener on the click event on the form submission button (I recommend doing so by setting an event handler on the window.load event), which prevents the default behaviour of the button and calls the function written above; event.preventDefault();

Set an action listener on the button press event, which then has a conditional to check if the enter key was pressed (we don’t want people bypassing the function, nor do we want to prevent people from submitting the form with the enter key, especially important for accessibility); $(document).keypress(function(e) { if(e.keycode || e.which) == 13) { e.preventDefault(); (call your function here);}});

Reference the populated field using HubL within your email template (using the {{ contact.field_name }} syntax mentioned by @zwolfson above).

I hope that makes sense to you. Please let me know if I can clarify any points.

Thanks for offering the additional clarification you are certainly correct that the logic done via HubL that depends on the contact property values will not work for email. If all you need to do is to leave it blank, that’s the default value for any non-valued property so you’ll be fine. However if you have more of a snippet that needs to be wrapped around the actual property value the best way to do that is let Smart Content handle that logic rather than worrying about doing that in HubL. You would set up a list in the UI for if the contact property is known. Then you can have a module with a smart rule dependant on that list where if they are on that list the content you want to show is displayed (including the property value itself). If they don’t meet that rule just leave it blank and that section will be collapsed.

@karl Thanks for chiming in here, that solution would have worked a while ago, however we no longer allow submission of arbitrary HTML content via form submissions. If you wanted to use one of our APIs (which are authenticated) to put HTML content into contact properties, you could apply the same principals here, depending on how we gather this type of information.