Website

Requested improvements to Events
We are currently testing HighLevel Events as a replacement for our existing seminar registration system. The Events product is very close to being usable for our needs, but several limitations currently prevent us from moving our live seminar registration process into HighLevel. Our use case is educational/seminar events where one person may register themselves plus a spouse, partner, family member, or other guest. We also need to know exactly which marketing source generated each reservation. The following enhancements would make HighLevel Events significantly more useful for seminars, workshops, dinners, conferences, and similar events. Allow Required Fields for Every Ticket / Attendee When someone reserves multiple tickets, we need the ability to require information for each individual attendee. Currently, certain fields on additional tickets cannot be made required. For example, we cannot require a phone number for the second attendee. We should be able to individually configure fields such as: * First Name * Last Name * Email * Phone Number * Custom Fields as Required or Optional for every attendee/ticket, not just the primary registrant. For our seminars, each attendee becomes an individual contact and may receive individual reminders and follow-up communication. Therefore, having complete contact information for every attendee is important. Option to NOT Automatically Copy Primary Registrant Information to Additional Tickets Currently, information from the primary registrant can be copied into the second ticket/attendee. There should be an event-level setting such as: Prefill additional attendee information using primary registrant information: ON/OFF When turned OFF, the second attendee fields should be blank and require the registrant to enter that person's actual information. For example: Attendee 1 John Smith [ john@email.com ]( mailto:john@email.com ) 239-555-1111 Attendee 2 [First Name Required] [Last Name Required] [Email Required/Optional depending on event settings] [Phone Required] We do not want the system automatically creating a second attendee containing the primary registrant's email address or phone number unless the registrant intentionally enters that information. Allow Multiple Attendees on RSVP Events Ticketed Events currently allow someone to reserve multiple tickets, but RSVP Events should also support this. For example: Number Attending * 1 * 2 * 3 * etc. If the user selects 2, HighLevel should display registration fields for the second attendee. This is especially important for seminars, dinners, workshops, webinars, community events, and professional events where a registrant frequently brings a spouse or guest but the organizer does not need to create a formal "ticketed" event. An RSVP should represent a reservation, and that reservation should be capable of containing multiple individual attendees. 4. Native Registration Source / UTM Tracking for Events We also need reliable attribution for Event registrations. HighLevel Events should automatically capture marketing attribution such as: * UTM Source * UTM Medium * UTM Campaign * UTM Content * UTM Term * Referring URL * Landing/registration URL * Registration Source These values should be available on the Contact, Event Registration, workflows, reporting, and ideally the Opportunity. For example, we may promote the exact same seminar through: * Direct Mail * Meta/Facebook Ads * Email * Referral Partners * Organic Website Traffic We need to know which source generated each reservation and attendee. Without this capability, it is extremely difficult to calculate marketing ROI or determine which campaigns are actually producing seminar attendees and clients. Allow Event Fields to Be Populated From URL Parameters As either part of native attribution or as a more flexible alternative, Event registration forms should allow fields to be populated from URL/query parameters. Example: website.com/event?source=mail or website.com/event?source=meta HighLevel should be able to map that value into a Contact custom field or Event Registration field. This would allow users to create separate campaign links while still sending everyone to the same Event registration page. Ideally, these values could also be passed through shortened or redirected URLs. For example: website.com/events/101 → Direct Mail website.com/events/102 → Meta website.com/events/103 → Email Hidden Fields on Event Registration Forms Event registration forms should support hidden fields. A field such as Registration Source should be capable of being populated automatically without being visible or editable by the registrant. For example: Registration Source = Meta The registrant should not see a dropdown asking them to select "Meta." The value should simply be stored with the registration. This could be implemented through: * A native Hidden Field type * A "Visible on Registration Form" toggle * URL parameter mapping * UTM mapping * CSS visibility controls The specific implementation is less important than having a reliable method of attaching invisible registration metadata to an attendee. We are actively attempting to move a real seminar operation into HighLevel Events. The existing Events functionality already handles many of the difficult pieces well, including creating individual attendee Contacts, multi-ticket registration, check-in, workflows, and downstream opportunity automation. However, the limitations above currently prevent us from using Events in production. The two biggest blockers are: Multi-attendee registration needs to treat each attendee as a true individual attendee with configurable required fields. Event registrations need reliable marketing-source attribution that does not require the registrant to manually select their marketing source. Ideal Registration Experience A user clicks a campaign-specific registration link. HighLevel silently captures the marketing source. The user enters: Your Information First Name Last Name Email Phone How many people are attending? * 1 * 2 If 2 is selected: Guest Information First Name Last Name * Email Phone The guest's fields are blank rather than automatically copied from Attendee 1. HighLevel then creates two individual attendees/contacts, associates both with the same reservation, preserves the registration source, and allows workflows to act on each attendee individually. That would solve the major limitations preventing us from moving our event registration process entirely into HighLevel.
0
·
Enhancement
PLEASE! Landing Page Builder Needs a Modern Drag-and-Drop / Responsive Editing Workflow
The current landing page builder is unnecessarily time-consuming and non intuitive compared to modern visual builders such as Wix, Webflow, Framer, and similar platforms. The primary issue is that a basic page construction requires excessive manipulation of sections, rows, columns, containers, margins, and padding instead of allowing elements to be positioned and arranged through an intuitive visual drag-and-drop interface. Nearly every element, including text, images, logos, icons, buttons, forms, and other assets, requires repeated manual spacing adjustments just to achieve basic positioning. Something that should take seconds through direct visual manipulation often requires navigating multiple containers and repeatedly adjusting padding or margin values. This dramatically increases production time for what should be straightforward landing-page design work. For a company like GHL that is predicated on being an entire marketing ecosystem, and landing pages being one of the most fundamental ways all clients drive traffic to for marketing purposes, you would think the landing page builder would be the strongest tool in the entire GHL platform, and it is the weekend, by orders of magnitude. Responsive editing is also a major issue. Desktop, tablet, and mobile layouts should function as independent responsive editing layers while maintaining the same underlying content. For example, I should be able to: * Build the desktop layout. * Switch to tablet and reposition, drag drop / resize, or adjust elements specifically for tablet. * Switch to mobile and independently optimize positioning, spacing, sizing, alignment, and layout. * Make those layout changes without destructively changing the desktop or tablet presentation. Currently, achieving substantially different responsive layouts can require duplicating elements and controlling their visibility across desktop, tablet, and mobile. This creates unnecessary duplication, pain staking page complexity, and makes ongoing maintenance significantly more difficult. A modern responsive builder should allow device-specific presentation properties without requiring duplicate content elements. Requested Improvements True visual drag-and-drop positioning for page elements rather than relying heavily on padding and margin manipulation. Independent desktop, tablet, and mobile layout controls while preserving shared content. Device-specific positioning, sizing, spacing, alignment, and ordering without requiring duplicate elements. Simplified container hierarchy so routine layout changes do not require navigating through multiple nested sections, rows, columns, and elements. Direct canvas manipulation, including dragging, resizing, aligning, distributing, and snapping elements visually. Improved responsive behavior so layouts intelligently adapt between breakpoints before requiring manual intervention. Clear visual indication of which properties are global versus device-specific so designers know whether a change will affect other breakpoints. Business Impact This is more than a UI preference. The current workflow materially increases production time as even in just making a minor adjustment in what should take 1 minute can sometimes take 30+ for literally no reason. Multiply that times an entire new page build can then be up to 5X+ longer in production time, the multiply that times 5-10-50 clients? It's a full non starter and I can only imaging GHL customers end up moving to other platforms to obtain a substantially better and more streamlined LP building experience. I would imaging that senior exec and product leadership teams would much prefer current customers solely rely on dependence of GHL so they can continue to work all in one native ecosystem, overall massively increasing the value of the platform and reducing churn rate. Net net. Building a professional responsive landing page can take several times longer than accomplishing the same work in modern visual website builders because so much time is spent manipulating containers, padding, visibility settings, and duplicate responsive elements rather than designing the page itself. For agencies or customers producing landing pages at scale, that additional production time directly increases the cost of delivering work through the platform. The landing page builder would be significantly more competitive if responsive design behaved like a modern visual design environment rather than requiring designers to manage the page primarily through nested containers and manual spacing values. In a day and age where people likely can vibe code enhancements into platforms for improvement, I hope there is a roadmap for the product and engineering teams to bring GHL's landing page out of the gilded age into a modern era responsive and efficient page builder. Thank you in advance -M
0
·
Enhancement
Load More