Overall, the new form editor with enhanced conditional logic is a VAST improvement with tons of promise, two big drawbacks in current beta state that are preventing us from actually testing in a client-facing capacity though -
Hidden Fields:
Currently, you cannot use hidden fields in the same way that you can with the legacy forms editor. You can hide fields when certain conditions are met, but in the old from, it was really helpful to be able to use hidden fields to pass values along to contacts/companies/tickets upon submission. Theoretically this is still possible with workflows (contact has submitted “x” form, populate with “y” values), but there’s a lot of reasons why it would be better to accomplish this natively in the form as opposed to through workflow. Both because of maintenance/number of workflows, and to keep a stronger hold on permissions around workflows in general.
Non-contact/company properties:
Currently, this is the big blocker in allowing us to actually test this beta with a public-facing form in the new editor. The new logic is a VAST improvement over what we had previously, but we’re primarily trying to create tickets based on form submissions to take advantage of this logic. In current state, the only way we could do that is creating a bunch of contact properties that we don’t have much use for and syncing them over to a ticket. Ideally, we’d be able to ask for ticket properties in the form editor same as we can in the legacy editor. Sync fields (with their various limits) is not a good solution here either, because we’d still be creating contact properties that have no use other than to be a container to sync over to a ticket, which is not ideal.
yeah I just assumed there would be ticket properties, it didn’t even occur to me that there wouldn’t. I’m VERY disappointed to find I can’t connect the new forms to our helpdesk, and it makes the new form editor basically useless to us.
Built a whole business process and form… Hype dup my leadership ont his new capability to use beta an dthen create tickets in Helpdesk. It’s not even freaking possible. Total wasted of time. WE need ticket properties, not just company and contact. Sheesh
We *love* the new conditional logic format (AND/OR is huge!) but currently we can’t use hidden properties for conditional logic. This is super important for us -- we have a lot of embedded forms in our app and website where we pass values from logged-in users to hidden properties. We’re able to build conditional logic from hidden properties in the legacy form builder -- wondering why that functionality wasn’t rolled over into the new builder? Fingers crossed it’s coming.
Just chiming in that I agree that adding ticket capabilities to the new editor would be a huge value. For us, the conditional logic features are more useful for tickets than any other type of form.
I’m also in a similar boat here. We definitely need the ability to use ticket properties in our forms.
Absolutely love the new form editor, the look, the way we use it, the look of the end product. Really confused why features from the Legacy form editor would be removed though. Before getting the Beta, we had showcased (to the executives) the form with the Legacy form editor, and that the New editor will allow us to do the same with a multi-page form.
I really need the ability to make multi-page forms with ability to use ticket properties, really don’t understand why this feature wasn’t carried over. Also in the Legacy editor, there’s a simply option to create a ticket with the form submission, while in the New editor, has to be done via workflows, another change that doesn’t make much sense to me.
Agreed! I’d like to use the new editor as I’m building a ticket form that has complicated logic which is much better in the new version, but I can’t use ticket properties which makes this impossible.
The AI form builder looks great following the small group demo. However until ‘ticket’ properties are easily accessible it would be really differcult to move to using this format as our business is ticket driven.
Hi everyone! My name is Hallie, and I’m an Associate Program Manager on our CXM team here at HubSpot. I’m happy to share that both of these features are now available - you can use hidden fields, and ticket properties in the new forms editor! You can read more about using hidden fields here, and using ticket properties in the new forms editor here.
Hello Hallie. Thank your for this update!
I realized that conditional logic is only possible if we have marketing hub enterprise. I have some customers with Service Hub Enterprise, and in spite of now I can include ticket properties in the new form editor, without conditional logic is not very useful.
Any chance to enable conditional logic for service hub enterprise?
Thank you
Jainme
@hhiggins can I confirm that the conditional hidden fields with logic is now only available to enterprise users? This was an essential feature for us, and to lose it is a huge loss.
I’m adding my input to this ticket.
I’ve noticed some gaps in the APIs for the new form system.
We’re reaching out to support to report a major technical issue encountered on several of our client portals. We develop custom web architectures based on Next.js and Directus, and integrate HubSpot forms via an in-house API connector to combine a high-performance front-end experience with the power of the HubSpot CRM.
Here are the details of our issue, organized by our specific roadblocks:
The Business Need
For our clients, conversion on complex user journeys requires advanced forms—specifically, forms capable of dynamically adapting to user responses (conditional display) and segmenting long entries into multiple steps (multi-page forms). This ensures an optimal conversion rate on our Next.js interfaces.
What Works in the New UI Editor
HubSpot’s new form editor offers an excellent native user experience (UI) on the CRM side for creating and configuring these modern forms (conditional fields, multi-step structure). The design and usability perfectly meet marketing expectations.
What’s missing on the API side
The APIs and development kits associated with the new form editor do not allow this logic to be rendered seamlessly and dynamically in a headless environment or via a custom API integration. More specifically, the identified roadblocks are:
The lack of native or documented support for properly retrieving and managing the multi-page structure via the API for custom front-end rendering.
The inability to dynamically render dependent properties (conditional fields) as smoothly as in the native HubSpot rendering.
Practical Impact / Roadblock
This lack of functional parity between the native UI and the new form’s APIs is blocking integration with our Next.js applications. We cannot deliver the interactive experience our clients expect on their websites, which directly harms the performance of their conversion campaigns.
This issue directly impacts the following current clients:
Aquamotion Courchevel (ID: 5145612104)
Rouen Normandie (ID: 147092394)
Just Arrived (ID: 25187101)
Why Using Legacy Forms Is Only a Workaround
Currently, we are forced to switch to the older, so-called “legacy” form type to get around the problem. However, this is not a sustainable solution for the following reasons:
Technical debt and sustainability: Legacy forms are likely to become obsolete over time, forcing us to rewrite our connector later on.
Loss of functionality: This deprives our customers of the performance and security improvements, as well as the new marketing capabilities, introduced in the new editor.
Ecosystem Inconsistency: Our customers manage their forms in HubSpot using modern standards, but encounter regressions or technical roadblocks whenever they try to use them outside of HubSpot-hosted pages.
Could you please escalate this issue to the Product/API team to find out if there are any roadmap plans or fixes scheduled regarding full exposure of multi-page forms and dependent properties via your APIs?
