Problem with Form module

Develop, Build & Integrate CMS Development
1

I’m having trouble embedding a form module in hubspot.
I would like to override the notifications email of the form like this

{% module_block form "my_form" form_to_use="{{ module.form_field.form_id }}", notifications_are_overridden=True, label="Form", overrideable=True %} {% module_attribute "notifications_override_email_addresses" is_json=True %} ["test@test.it"] {% end_module_attribute %} {% end_module_block %}

Like this it works, but I don’t want to put “test@test.it”, but I want to take the emails form an hubdb with some logic.
I tried with a simple list of strings: {% set emails = ["test1@test.it","test2@test.it"] %}
and then pass it to the attribute module like this: {{ emails|tojson }} which should print exactly ["test1@test.it","test2@test.it"].

But the emails don’t arrive. What am I missing?

3

Hey @MBaldoni,

Thanks for bringing this to the Community!

Here are a couple of resources that could point you in the right direction: HubL standard tags - Form and Block syntax.

In the meantime, I’d also like to tag in some of our Contributors to see if they have any tips and tricks on this!

Hey @UlianaV, @evaldas, @MichaelMa – Do you have any suggestions for @MBaldoni on this?

Thank you!!

Sam, Community Manager

4

Hi @MBaldoni!

The issue is likely that Module attribute expects a static JSON value at compile time, and it doesn’t always evaluate HubL variables or expressions the way you’d expect inside the block.

Although {{ emails|tojson }} renders the correct JSON when output on the page, it isn’t necessarily interpreted as the value for notifications_override_email_addresses within the module definition.

A couple of things you could try:

  • Verify that your emails variable is actually being rendered as valid JSON by temporarily outputting {{ emails|tojson }} elsewhere in the template.
  • If you’re pulling the emails from HubDB, make sure you’re ending up with an array of strings (not objects or a comma-separated string).
  • If the rendered JSON is correct but notifications still aren’t sent, it may simply be a limitation of the module_attribute tag, which doesn’t currently support dynamically generated values for notifications_override_email_addresses.

As far as I know, the notification override is intended to be configured with a static value. If your use case requires the recipients to be determined dynamically from HubDB or other runtime logic, that isn’t currently supported through the form module.

I’m curious to see if anyone else has found a workaround, but based on the documentation and my experience, this appears to be a current limitation rather than an issue with your JSON formatting.

5

I would not make the form module notification override the dynamic part here.

The static JSON works because the form module can read that value as module configuration. Once the recipients come from HubDB logic, you are depending on a runtime HubL expression being interpreted as the module attribute value, and that is the fragile part.

The cleaner pattern is:

  1. Keep the form notification config static or empty.
  2. Add a hidden field with the routing key you already know on the CMS page, for example region, office, product, or HubDB row id.
  3. After submission, use a workflow branch or custom-code action to send the internal notification to the right people.

If you still want to test the current approach, output the final value next to the form temporarily and make sure it is an actual JSON array of email strings with no empty HubDB rows. But even if that renders correctly, I would treat workflow/custom-code routing as the safer production setup.

6

Hi,

thank you all for the support, I found a solution and the problem was indeed that the json wasn’t compiled in time. So before the json could be compiled the form was, so to the form was passed literally {{ emails|tojson }} instead of my compiled json. I also tried with |render filter but was unsuccesfull.
The solution, which works, suggested by HubSpot DOC AI is the following:

{% set email_override_block = '{% module_attribute "notifications_override_email_addresses" is_json=True %}' ~ matchingNotificationEmails|tojson ~ '{% end_module_attribute %}' %}

{% module_block form "my_form" form_to_use="{{ module.form_field.form_id }}", notifications_are_overridden=True, label="Form", overrideable=True %} 
  {{ email_override_block }}
{% end_module_block %}
7

Thank you for the suggestion, that would be a clean solution, but it would rely on external parts, which I was trying to avoid