Great minds think alike

When form submissions display in the timeline, it lists the fields in alphabetical order. This seems like a mess to view and there should be options to sort them by the field order in the actual form that displays on the website page and then contain the other info.  For instance, I'd love to have it show First Name Last Name Email Delivery Date (custom form field) Calculated Cost (custom form field) The way it is now, it displays a bunch of stuff we don't even need right away and we have to sort through the info (in alphabetical order). Became an opportunity date Calculated Cost City Create Date Desired delivery date. and so on with a lot of alphabetical fields....seems SLOPPY ...read more

It might be helpful for our customers to switch to a system for form submissions that deduplicates/updates existing properties on contact records via a matching email address, rather than a matching cookie. Right now, HubSpot deduplicates contacts from form submissions by looking for an existing contact record based on matching cookie. In this instance, is a cookie matches but a new email address is submitted, the existing email address and all other values submitted will be appended rather than creating a new contact. I've seen this cause issues in two scenarios: 1. With HubSpot forms, there is a setting to Always create contact for new email address. This setting ignores the existing cookies when a new email address is submitted, and creates a new contact. However, turning this setting on leads to a scenario where we cannot use Progressive fields or prepopulate form fields with known values. It would be helpful to be able to deduplicate contacts based off email address in this scenario because while the existing cookie might display different form fields to the user, customers may prefer creating new contacts with new information rather than appending existing records with wrong information. 2. With non-HubSpot forms, there is not a setting to "Always create contact for new email address." In this instance, the only recourse I have found to stop HubSpot from appending existing records based on matching cookie is to stop utilizing HubSpot cookies entirely, or to enter from an incognito window. If deduplication/updating existing records was done based on email address submitted, customers would have more control in this scenario. ...read more

Target Group of Idea Admins of multi-country organisations Companies with strict legal teams which take data protection serious Improvements desired Data Privacy & consent defaults: Allow manually adding languages for companies with several legal entities this makes sense. As soon as you have 2 countries sharing a language you need 2 sets of defaults (for mentioning different legal entities in the GDPR options below a form). Right now you can set only a single default and the second country would have to edit the values every time when they create a form.   Data Privacy & consent: Default text per language and per subscription type Right now you can set a single default text per language that all subscription types will share. This makes little sense when you have several valid subscription types that have different content (say "newsletter" and "event notifications"). Right now independent of which subscription type you select in a form it will show a single text as default (which means again that you have to manually overwrite this every time you use a different subscription type).   GDPR texts and subscription types: granular permission management User permission setting to allow/disallow editing of GDPR texts and subscription type texts (what is shown next to the checkbox) when creating a form. Right now you can align the perfect legal texts with your legal department, but every marketeer can use a different version under their form User permission setting to allow/disallow creation/editing of subscription types. Right now this is connected to email permissions, but in larger organizations you want people to write emails without being able to create their own STs Versioning of subscription type default texts Store the history of all subscription type texts (descriptions and values used in forms) and store on contact level which version someone agreed to. This needs to be searchable in lists/workflows/... so that you can treat contacts with different versions differently. Example: only people with V3 upwards of our marketing consent get surveys since before we only asked for newsletters reception.   Store the exact wording of a GDPR consent checkbox's text in the "Subscription Change" event on contact level Imagine the following: you have 20 different forms using the GDPR checkbox for "consent to communicate" that all reference the same subscription type. Different people work on these forms. Over time the consent texts change. Since right now all your marketeers can overwrite the consent texts in each form and the changes are not even versioned, you will come into the situation where you do not know what a contact with a certain subscription type has actually agreed to. When your consent says "I agree to receive marketing content from time to time" and later (or in different forms) the text for the same subscription type is "I agree to send my firstborn to work in the mines of your company", it would be great to actually be able to see & prove what the contact agreed to. Right now you just cannot. Therefore I suggest to store the exact wording of the checkbox at the time of the opt-in on contact level in the event "Subscription change".   Value Add Big step forward for admins of bigger/international companies since right now those cannot ensure that consents and legal texts are used consistently. Legal safety of actually being able to prove what a contact agreed to. Preventing subscription type chaos as an admin. Save form creators a lot of work (overwriting text defaults that are wrong for their country or overwriting subscription type texts that are wrong) Reduce errors that happen when you need the absolutely correct texts below a form, but the process relies on form creators remembering to copy and paste the correct texts from another place into their hubspot form ...read more

I raised this issue with HubSpot support - and unfortunately recieved a less than helpful "this isn't a bug" response. But I am documenting it here for other people who will inevitably have the same or similar issue.   The problem: HubSpot's embedded forms have 2 callbacks that are very similar yet act very differently:   onFormSubmit onFormSubmitted   The main difference being the order in which they are executed, (onFormSubmit before onFormSubmitted). However, the main issue is how HubSpot executes these callbacks in the context of form field validation.   All hubspot form fields are validated prior to the onFormSubmit callback being run. EXCEPT the phone number field. The phone number field validation is performed AFTER the onFormSubmit callback executes. Which doesn't seem like a problem, until you realize that:   The documentation explicitly says: "Callback that executes after form is validated" The onFormSubmit callback is passed a $form argument that allows you to access the form field values (useful for any advanced redirect logic or tracking necessary post-submission). The onFormSubmitted callback is not passed this same argument - therefore the callback is practically useless if you need to access the form field data at the point of the submission lifecycle. So, if you utilize an onFormSubmit callback on a form that has a phone number field, and the form is submitted with an invalid phone number, the onFormSubmit callback will execute (even though it shouldn't as stated in the documentation).   This IS a bug, all other form fields are validated prior to the onFormSubmit callback being executed, but for whatever reason, phone number fields don't operate in this fashion.    PLEASE I beg you HubSpot - fix this. All fields should be valid before triggering either of those callbacks, and the current way it is built requires some extra hacky global variables to pass the $form object to the onFormSubmitted callback.   Also of note - the global callbacks suffer the same issues - the only difference being that the onFormSubmitted callback isn't passed a data property containing the form field values (similar to what is mentioned above).    My support ticket for reference is #8566325 ...read more

Migrated from legacy feedback forum with 8 votes.   The leadflows that exist were great however it would be fantastic if certain people could see certain leadflows from the same page i.e. a marketing qualifed lead would see a "Download this guide" pop up lead flow while a sales qualified lead would get a "Try our free trial" pop up lead flow ...read more

It would be a great addition to  be able to give users read-only access to forms, so that they can view, but not edit, forms. We have similar permissions for lists and workflows, why not forms?   Yes, users can view some details about forms by creating a filter or a view, but that is tedious and not a great user experience. They want to be able to see the actual form, who submitted and when.   I am now forced to to give access to forms to people that I don't want to give access to - not ideal. ...read more

There's no where to see what workflows a form is part of.  I can see Landing page but the form may be on numerous pages.    If we just want to check what the follow up progress is after a certain form ois complete we have to try remember the name of the workflow to look it up, it was easy at the start for me as I created everything but as we build up so many workflows and all the team are adding it’s hard to see where it is and what it does.    If we look up by landing page we may find one workflow but in actual fact the form might be in two workflows.  thanks  ...read more

It would be great if we could utilize custom fonts within forms. Right now, the only options are HubSpot default fonts and Google Fonts.  ...read more

Currently, date picker field can pick any date (on the date of visitor visit to website, past date, and future date).  It would be great if we can have an option to limit or customize the date range.  My use case is when I create a landing page for visitor to book an appointment for visiting our model house, we ask visitor to provide us with 3 best dates and time.  We want to customize the date range that visitor can select after 3 days on the day they submit a form. This way, we can arrange and reply to our contact to provide best timing.    The workaround that I can think of now is using meeting tool, but once a contact book a specific time slot, it will not be available for other contacts, and we want to give flexibile date and time range.    ...read more