Forms

Summary The form_embed.js script (included with form/calendar embeds) unintentionally hides third-party iframes on the same page when their src URL contains path segments like /booking, /form, /survey, /quiz, /group, /rentals, or /service-menu. Steps to Reproduce Embed a GHL form or calendar on a page that also contains a third-party iframe Ensure the third-party iframe src contains any of the above path segments (e.g. an Office 365 booking page at https://outlook.office365.com/owa/calendar/.../bookings/ ) Load the page Expected Behavior form_embed.js should only affect GHL-owned iframes and leave all third-party iframes untouched. Actual Behavior The Me() function in form_embed.js uses broad string matching (e.g. src.includes("/booking")) to identify GHL iframes. Any third-party iframe whose src URL happens to contain one of these path segments is incorrectly identified as a GHL iframe. It is then hidden via display:none / visibility:hidden by the de() function during initialization and never shown again, because it never sends the expected iframeLoaded postMessage that GHL uses to trigger the show sequence. Affected URLs / Example Third-party iframe src: https://outlook.office365.com/owa/calendar/***/bookings/ Matches because: src.includes("/booking") returns true Root Cause The Me() / Ie() filter in form_embed.js identifies GHL iframes purely by URL path segment pattern matching rather than by origin domain or a dedicated HTML attribute. This is not specific enough to distinguish GHL iframes from third-party iframes. Workaround A client-side interval loop is required to repeatedly force the hidden iframe back to visible after GHL's script runs, which is not a sustainable solution. Please let me know if you need any additional detail or a reproduction case.

When using sticky contact and the name, email, and phone number is different it should create a new contact or find THAT existing contact. Instead, sticky contact feature is updating the contact information for the contact who is sticky on the browser with the new submission's information. This is a MAJOR issue as this creates a scenerio where the CRM is incorrect and it does not inform the subaccount users that this has happened. You would have to constantly monitor every conversation to be able to tell if this occurs.

In the Form Builder when using the HTML field for custom scripts: The custom code security validator has a bug in its regex pattern for detecting dynamic function creation. The regex /(?:^|\W)(?:new\s+)?Function\s*\(/gi uses the case-insensitive flag (i), which causes it to match the standard JavaScript function keyword (always lowercase) in addition to the actually dangerous Function constructor (always uppercase). These are fundamentally different — function() {} is a normal function expression, while new Function("...") is dynamic code creation equivalent to eval(). As a result, any custom code containing basic JavaScript patterns like setTimeout(function() { ... }), .forEach(function(item) { ... }), or var x = function() {} is incorrectly rejected with the error "Dynamic function creation (new Function) is not allowed for security reasons." The fix is to remove the i flag from the regex, making it case-sensitive so it correctly targets only the uppercase Function constructor. This is in the validation logic found in index.ff0b8ec0.js (around byte offset ~3,778,500, within the array processed by function Ly).

In both forms and surveys, there is no way to edit the title of the auto-complete section in the address. You can change the title and placeholder for everything else, but you can't modify the address auto-complete section at all.

To be GDPR compliant we have to add a hyperlink in a text box before the button subscription.

The search bar and keyboard comes up when accessing a dropdown custom field within a form on mobile. It doesn't make sense that a keyboard would come up for a dropdown item vs. a fill in. As a result, the dropdown choices are falling under the keyboard and some can't be accessed. GHL support said there is no way to disable the search bar. They suggested using radio buttons but that would not be practicle in this case. I appreciate the help. Please address this issue in a feature update.

Right now, a customer can select multiple products on an order form, but if I want them to select ONLY ONE, they have to ensure that they only select one. My concern is that a customer is going to accidentally choose both a monthly and a yearly plan on our saas checkout page, vs only choosing one or the other.

In HubSpot, when someone fills out a form, the submission data goes into the conversations tab, and agents can reply. Is this not the basic functionality of any CRM? How are agents to effectively deal with incoming form submissions if they do not come into the inbox? Please tell me I am just having a brain fart and this is possible.

The validation messages when filling out a form are unusual/non-standard for forms, such as the email field. I would consider this a bug. Example: Email field. If you enter an invalid email, the validation message says "Guest email is invalid" but this is an unusual message for this. It should be something akin to "Please enter a valid email address." A message like "Please enter a valid email address" applies to both leaving the required field empty AND the email being invalid. The best solution to this overall would just be to allow us to set the validation error message ourselves. In general we should be able to set custom validation messages on each field, so this is also an enhancement. Example 2: Checkboxes. If I have a checkbox field that requires at least one to be checked, the validation message is not very good. Let's say I have a checkbox field called "Subscribe to" and the two boxes are "Newsletter" and "Podcast." If neither are selected, the message will be "Subscribe to is required." This is technically correct, the field is called "Subscribe to," but it would be much better if a custom validation message could be set to say "Please select at least one option." I have seen this ability in other form builders, such as Forminator, where a custom validation message can be set. At the very least, it should be easier to change this. Currently, it requires a fair amount of custom code in an html element that uses css and javascript. Due to the html element not allowing anonymous functions anymore it is quite a bit of lines of code to cover all the bases.

Currently, the default form error messages in Go High Level are not fully translatable or customizable. For example: When leaving the email field empty, the error shows in our language (“E-mail address is required”). But for phone numbers it still shows in English (“Phone number is required”). Other validation errors like “Email is invalid” also remain in English. This creates inconsistency and limits the user experience for non-English speaking markets. Feature request: Make it possible to fully customize form error messages. Allow translations into any language (multi-language support). Enable us to set different messages per validation type (required, invalid, formatting, etc.). Optionally, allow branding/personalized messages for better UX. This would make GHL forms much more professional and user-friendly across different countries and languages.