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.

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.

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

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.

Ticketed Events currently allow someone to reserve multiple tickets, but RSVP Events should also support this.

For example:

* 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.

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:

or

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:

→ Direct Mail

→ Meta

→ Email

Event registration forms should support hidden fields.

A field such as 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:

Ideal Registration Experience

A user clicks a campaign-specific registration link.

HighLevel silently captures the marketing source.

The user enters:

* 1

* 2

If 2 is selected:

* Email

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.