topic Bug fix: Display Label for Custom Enumeration Properties for Custom Quotes in Developer Announcements

Bug fix: Display Label for Custom Enumeration Properties for Custom Quotes

dennisedson — Thu, 23 May 2024 21:06:14 GMT

Beginning May 21, 2024, we deployed a fix to how custom enumeration properties are displayed on custom quote templates. During this rollout, we discovered that the fix adversely affected some templates. As a result, we have paused the rollout.

If your template was affected by this change and you need time to update it, please submit this form, and we will temporarily revert your account to the previous functionality.

What’s Changing?

When creating a customized quote template, developers can create custom dropdown (enumeration) properties. Each property has an internal value and an external label. The quote output should display only the external label, but it was displaying the internal value instead.

We will resume deployment of the fix to ensure that the external label is displayed correctly, rather than the internal value.

Developers will need to update their templates by removing references to the internal value of custom enumeration properties and replacing them with the external label.

When is this happening?

Beginning August 21, 2024, we will resume the rollout of this fix. This will include all accounts that requested a temporary exception.

Re: Bug fix: Display Label for Custom Enumeration Properties for Custom Quotes

PD_ — Tue, 28 May 2024 16:38:38 GMT

Hello. I'm one of the people who had to scramble to figure out why my quote templates weren't rendering correctly, just to find out that HubSpot made a change without telling me. Since it took several days for the tech support person to let me know that this was an intentional change, I'm supposing the tech support personnel weren't informed either.

These are the reasons I gave to HubSpot tech support when I was suggesting this change shouldn't happen:

1) We should be free to modify a label without it breaking quote templates. A label is for internal display purposes and we should be able to change it to, say, a more clear or descriptive label. A person who didn't write the the quote template may change a property label, assuming that it wouldn't break anything.
2) Depending on the label instead of the value in a quote template is not something someone would expect. In programmer parlance, it violates the principle of least astonishment. See https://en.wikipedia.org/wiki/Principle_of_least_astonishment
3) It's a change in behavior. It's likely that other people using custom quote templates will find their templates broken, even if they don't currently notice.
4) It's undocumented. Nowhere in the HubSpot documentation does it indicate that a label will be used instead a value.
5) The data given to the template differs from the data shown when you objects using the HubSpot API. A boolean property, for example, will show "Yes" in the quote while the API returns the property as "true".
6) Depending on the property, it may not make any sense to use the label instead of the value. In my case I was using a boolean property to cause something to hide or show. The property value would never be output for the customer to see, so it didn't make sense to use the label.

Even if a change is required, Hubspot should communicate better about changes. Please follow the pattern that AWS uses for communicating changes like this:

1) Notify in well in advance
2) Explain the reasoning for the change
3) Give an exact date when the change will happen
4) Repeat notifications in case the previous notifications were missed
5) Use multiple communication channels if possible. For example, email and alerts within the web portal.

Alternatives to this using labels as values for custom enumerations:

If people want to use the label instead of the value, HubSpot could provide a new Hubl function. For example: get_label_for('type','property_name',value)

Or the customer could be instructed to make the value the same as the label for that the custom enumeration property.

Re: Bug fix: Display Label for Custom Enumeration Properties for Custom Quotes

NBach — Wed, 29 May 2024 13:47:16 GMT

Thank you for the feedback! I want to echo and acknowledge that we need to communicate better about changes like this. To start, we’ve paused the rollout of this update until August 21st so that users can prepare and adjust to this change. We will ensure that any changes in the future are better communicated and apologize for the inconvenience this change caused in the interim.

For context, we based this change off of customer feedback and preference for the label to be displayed (not the value). Although the custom enumeration properties are flexible and can be used in a variety of ways, we were solving for the issue of which part of the property is rendered on the quote.

That being said, thank you for the suggested solution of introducing a new Hubl function. We will look into this and let you know if it’s something we take on.

Thank you again for your feedback and please let us know if you have any other thoughts or suggestions, as we’re always looking to improve.

Re: Bug fix: Display Label for Custom Enumeration Properties for Custom Quotes

HubDoPete — Wed, 05 Jun 2024 09:55:23 GMT

Hi @NBach

Like @PD_ , we had multiple customers impacted by this change, as we have many custom templates coded to behave differently based on dropdown property option values. For example:

Payment, Shipping and Delivery terms that are stored on the Buyer Company record or Deal, but displayed on the quote in the language of the quote template. We must reliably know the dropdown terms code from their ERP to control what to display on the Quote.
Three-letter ISO country codes of the buyer company, to control displaying or hiding additional terms.
Inclusion of extra instructions on a quote based on multiple dropdown selections on each line item such as Colour, Size, Fabric...

I understand why you had feedback from template designers who want to display dropdown properties on the quote page, without having to convert them via theme dictionaries. But we cannot deterministically program the template behaviour if we cannot read the internal value of the dropdown setting. I also get that the change was based on customer feedback, but it wasn't based on feedback from those of us relying on the existing behaviour.

I agree with @PD_ that a HubL feature would be best.

Either as the function example shared, or maybe a filter?

for example: property_name|option_value and property_name|option_label with the default non-filtered output being option_value as it is today, so that existing templates in non-upgraded portals do not also break in August.

Looking forward to more clarity on how this will roll out in August so we can build workarounds if required.

best

Pete.