EventEngine blog

How to build an event landing page in HubSpot

Phill Burrows — Mon, 06 Jul 2026 11:19:06 GMT

I've reviewed a lot of event landing pages in client portals over the years. Most of them fail in the same 2 or 3 ways, and none of those ways are about design.

The page is usually pretty enough. What's missing is the date above the fold, or a form short enough that people finish it, or a thank-you page that does anything at all.

So here's the full build, in HubSpot, as I'd do it for a client. If you want the wider picture of running events in HubSpot, that's a separate guide.

What the page has one job to do

Get a registration. Everything on the page either helps that or gets in the way.

A visitor decides in seconds, and they need 3 answers fast: what is this, when is it, and is it worth my time. Put all 3 above the fold with the form or a button that jumps to it.

The amount of scrolling between a visitor and the form should embarrass you slightly. If your event page opens with a full-screen hero image and a brand statement, the date buried somewhere below, you're paying for that in registrations.

The build, step by step

1. Start from a landing page, without site navigation. In HubSpot, create a landing page rather than a website page. Strip the menu. Every link that leads away from the form is a door out of the room, and the nav is 6 doors.

2. Write the header block first. Event name, one line on why it matters, date and time with timezone, format (webinar, in-person, hybrid), and location or platform. For webinars, the timezone matters more than you'd think. I've watched a UK company lose a chunk of US registrants who assumed EST and found out at 2pm that they'd missed it.

3. Build the form. Name, email, company. Stop there unless sales genuinely needs more. Every field past 3 costs you registrations, and you can enrich the record later. If most registrants are already contacts, turn on progressive profiling and let HubSpot swap in new questions for known people.

4. Add the body content. Agenda with rough timings. Speakers with faces (real photos, not LinkedIn exports from 2019 if you can help it). A short paragraph on who the event is for, which does more filtering work than any amount of copy about how great it'll be.

5. Create the thank-you page. This is the most skipped step and the cheapest win. The thank-you page should confirm the details, hand over an add-to-calendar link, and offer one next step, like a related resource or a speaker's LinkedIn. HubSpot won't generate the calendar file for you, so create an ICS file and link it here and in the confirmation email.

6. Check it on a phone. Half your traffic, sometimes more, arrives from a LinkedIn post or an email on mobile. The form, the date, and the register button all need to survive a small screen. HubSpot's preview does this in 2 clicks and people still skip it.

7. Set the social image. When the page gets shared, the og:image is the ad. A branded card with event name, date, and speaker faces will outperform whatever HubSpot picks by default from the page.

After the event, the page still exists

Set a reminder for this because nobody remembers it on the day.

Once the event's done, the page should either redirect to the recording, swap its form for a "watch on demand" version, or point at the next event. A live registration form for an event that happened last Tuesday is a small credibility leak, and search engines will keep sending people there for months.

On-demand pages are quietly productive, by the way. A webinar page that converts registrations for 6 months afterwards often beats the live number.

The part that gets old fast

One page, built carefully, takes a couple of hours. Fine.

Then it's every event. Clone the page, the form, the thank-you page, the confirmation email. Rename all of them. Update the date in 5 places, and the timezone, and the speakers. The cloning itself is quick. The mistakes are what cost you, and they're always the same mistake: one asset in the chain still holding last month's details.

At a handful of events a year, you live with it. Past that, it's worth automating. This is what we built EventEngine for: you create the event record in HubSpot and it generates the landing page, registration flow, and comms from that single source, so the date only exists in one place and can't drift.

Either way, build the manual version at least once. You'll understand exactly what your event pages need, and you'll know what any tool you buy later should be doing for you.

HubSpot event management: the complete guide

Phill Burrows — Mon, 06 Jul 2026 10:57:23 GMT

I've built event processes inside HubSpot portals for years, first as an implementation consultant and now as someone who builds event software for the platform. So I've seen the whole spectrum: teams running 3 webinars a year off cloned templates, and teams running 50+ events who've quietly hired someone just to manage the admin.

This guide walks you through the full build, in order. Data model first, then setup, then assets, then automation, then reporting, then the decision about whether to keep building at all. Work through it in sequence. Each step makes the next one easier, and skipping ahead is how portals end up in a mess.

Before you start: know what you're working with

More than most people think, is the answer. On Marketing Hub Pro you already have landing pages, forms, marketing emails, workflows, lists, and campaigns. That's most of an event stack.

You also have the marketing events object. It's a dedicated record type for events that tracks who registered, who attended, who cancelled, and (for webinars) how long they stayed.

One catch though. The marketing events object was designed to be fed by integrations. Connect Zoom or Teams and registrations flow in on their own. Run an in-person event off a HubSpot form and you're wiring it up yourself, or importing a spreadsheet afterwards.

Keep that catch in mind. It shapes several of the steps below.

Step 1: decide where your event data will live

Start here, before you build a single page. Everything else in this guide hangs off this decision, and it's miserable to change later.

You've got 3 options, and I have a firm view on them.

Contact properties. A property like "Registered for June webinar", then another for July, then another. This breaks by event number 3. You end up with 40 stale properties and no way to ask "which events has this person attended this year?"

The marketing events object. The right default for webinars, since the integrations do the work. Usable for in-person events with some workflow wiring. Its limits show up in reporting, which we'll deal with in step 5.

A custom object. The clean model: an Event object with registrations as associations. Each event becomes its own record, and you can query any contact's full event history. But custom objects need Enterprise, and you're building registration logic, comms, and reporting yourself. I've built this for clients. Budget serious hours.

If you're on Pro, pick marketing events and keep your naming ruthlessly consistent. Decide the naming convention now, write it down, and don't deviate. Future you, staring at a report filter in step 5, will be grateful.

Once you've settled this, and only then, move on.

Step 2: set up the marketing events object

With the data model decided, wire up the object itself.

If you're running webinars, connect your webinar platform first. The Zoom integration is the most mature: it creates the marketing event, syncs registrants both ways, and writes attendance duration back to the contact after the event. That last part matters because "attended for 4 minutes" and "attended for 55 minutes" are very different sales signals.

For in-person events, create the marketing event manually and use form submissions plus a workflow to set registration status. It's clunkier than the webinar route, but it keeps everything in one place, which pays off when you get to reporting.

Do this step properly and registrations now land somewhere sensible on their own. That frees you up to build the things your audience actually sees.

Step 3: build the event assets

Here's what one ordinary webinar takes. Treat this as your build checklist:

A landing page
A registration form
A thank-you page
A confirmation email
An add-to-calendar file for that email
Two reminder emails (day before, hour before)
Follow-up for attendees
A different one for no-shows
An active list of registrants
Two or three workflows to send all of the above
A campaign to group everything for reporting

That's 12+ assets. Build the first set carefully, because these become your templates. Your first event is a day or two of work. Once you've got templates to clone, call it half a day per event.

Half a day sounds fine until you multiply it. At 30 events a year that's 3 weeks of someone's time spent cloning and renaming assets. And cloning is where mistakes live: the reminder email that still says the old date, the workflow enrolling people from last month's list. Every marketing team I've worked with has sent at least one of those.

You now have the kit for one event. The next step is making sure you barely touch it again.

Step 4: build the 4 workflows that pay for themselves

Build these 4 workflows before your first event goes out. They earn their keep immediately, and having them in place means step 6 mostly runs itself.

Confirmation on registration. Triggered by form submission or marketing event registration. Include the add-to-calendar link. HubSpot doesn't generate ICS files natively, so you'll need to create one and host it, or use a free ICS generator. A calendar entry does more for attendance than any reminder email.

Reminders. Day before and hour before. The hour-before email should be one line and a join link. Nobody reads more than that 60 minutes out.

Branching follow-up. One branch for attended, one for no-shows. Send the no-shows the recording with a soft next step. Attendees get something with more intent behind it. A link to book time with sales, say, or early access to whatever you announced. If you send both groups the same "thanks for coming" email, you've wasted the one segmentation signal the event gave you.

Sales notification. If a contact who's an open deal or a target account attends, their owner should get a task the same day. This is a 10-minute workflow and it's the one sales will actually thank you for.

Once these 4 exist, an event can run start to finish without you babysitting the comms. Which matters, because on event day you'll have better things to do.

Step 5: set up reporting before the first event goes live

Do this before launch, not after. Retrofitting reporting onto 6 months of inconsistently named events is a punishment I wouldn't wish on anyone.

Group every event's assets under a campaign. That gets you influenced contacts and, if your deal associations are clean, influenced revenue per event.

Now the honest limits. Cross-event reporting in native HubSpot is hard work. Registrations live in form submissions, attendance lives on the marketing event, revenue lives on deals, and the joins between them depend entirely on how disciplined your naming has been since step 1. Asking "what did our event programme contribute to pipeline this quarter?" means assembling 3 or 4 reports and a fair amount of squinting.

It's doable. But if a clean answer to that question is something your leadership expects quarterly, factor the reporting time into the true cost of running events natively.

Step 6: run the event and capture attendance

If steps 2 and 4 are done, the run-up takes care of itself: confirmations, calendar files, and reminders all fire on their own.

For webinars, attendance flows back automatically through the integration, including how long each person stayed.

In-person is the weak point. There's no native check-in, so most teams export a list, tick names off on a clipboard or a spreadsheet, and import the result the next day. If that's you, do the import within 24 hours while the follow-up emails still feel timely. It's exactly the kind of job that gets done badly at 6pm after an event, which is why it needs to be someone's actual job rather than an afterthought.

Get attendance in, and the branching follow-up from step 4 does the rest.

Step 7: do the maths, then decide whether to keep building

After a few events you'll have real numbers. Here's my rough rule from client work: under 10 events a year, native HubSpot with disciplined templates is fine. The admin is annoying but manageable.

Past 10, the cloning tax compounds and the gaps start costing real money: no ticketing or payments, no capacity limits or waitlists, no QR check-in, manual attendance for anything in-person, and reporting that eats a day per quarter.

That's when an event app for HubSpot earns its subscription. There are a few in the marketplace, hapily and SimpleEvents among them. Full disclosure: I build one. EventEngine creates the landing page, registration flow, comms, Zoom sync, and QR check-in from a single event record inside HubSpot. The 12-asset build from step 3 becomes one form.

Whichever route you take, keep the event data in your CRM from the first registration. I push this on every consulting client. A spreadsheet of attendees turning up 3 weeks after the event helps nobody, and by then sales has moved on anyway.

Start at step 1 and work down. If you find yourself cloning the step 3 checklist for the 15th time this year, you already know what to do!

How to install EventEngine in your HubSpot portal

Admin — Thu, 25 Jun 2026 10:54:58 GMT

Category: Getting Started · Audience: HubSpot admin · Reading time: about 4 minutes

Installing EventEngine takes about 10 minutes. You connect it to your HubSpot portal, approve the access it needs, and run through a short setup. EventEngine handles the rest, building everything it needs inside HubSpot for you. This guide is written for the person doing the install, usually a HubSpot admin.

Before you start

A HubSpot Professional account, with admin access so you can approve the app's permissions. EventEngine needs Professional-level workflows and HubDB, so it does not run on free or Starter. You do not need Enterprise.
Your billing details to hand. EventEngine starts with a 14 day free trial, then moves to a paid plan.
A decision on who your event emails come from. You set the sender name during setup, so it helps to know it in advance.

Install EventEngine, step by step

Start the install. Go to the EventEngine install page, either from the HubSpot Marketplace listing or from eventenginepro.com, and click Install EventEngine. Already set up an account? Choose Sign in instead.
Choose your HubSpot account. EventEngine asks which HubSpot account to connect. Pick the portal you want to run your events from. If you are logged into more than one, HubSpot lets you choose.
Grant the permissions. HubSpot shows the access EventEngine needs. This screen is standard for any connected app, and EventEngine needs each item to do its job. Review the list, then click Connect app.

The access covers: the EventEngine Registration App Object (its records, custom properties and schema); contacts and contact lists; contact property settings; marketing events; Workflows; Content (sites, landing pages, CTA, email, blog, campaigns); Files; Forms; HubDB; and basic account information.

Why each permission?

The EventEngine Registration App Object and marketing events hold your event and registration data. HubDB and Content render your event pages. Forms power registration and Content covers the confirmation emails. Workflows run the automation behind reminders and follow-ups. Because registrations live in EventEngine's own App Object, not a HubSpot customer custom object, you do not need Enterprise.
Log in to EventEngine. After connecting, you land on the EventEngine welcome screen. Enter your email and password to continue setting up EventEngine for your portal, then click Log In & Continue. First time here? Create your account at this step.
Start your free trial. Choose your plan. EventEngine begins with a 14 day free trial, then enter your billing details to continue. You will not be charged until the trial ends.
Add your company details. Fill in your company information. EventEngine uses these basics across your events.
Set up categories and divisions. Add the categories and divisions, or groups, that you run events under. A couple to start with is fine. You can add more later, so do not overthink it here.

EventEngine now creates its modules inside your HubSpot portal. Leave the 'Creating EventEngine modules in HubSpot' screen to finish.
Set your event email settings. Set the sender name and details for your event confirmation and reminder emails, and choose your reminder timings. These are the emails your registrants receive.
Review and publish the workflow. EventEngine sets up its core workflow. This is the single automation that handles registrations across all your events, so you never build a workflow per event. Click Get Started to review and publish it.
You are in. EventEngine finishes by creating your email workflows, then drops you on your Events dashboard. It is empty to begin with. From here you can create your first event.

How to check it worked

Your EventEngine Events dashboard loads, with an empty events list ready for your first event.
In HubSpot, the EventEngine assets now exist in your portal: the shared registration form, the core workflow, the HubDB tables, the CMS templates, and the EventEngine Registrations object.

If anything is missing, the install did not finish cleanly. Try the setup again, and if it still falls short, contact support@burrowsconsultancy.com.

How to auto-register contacts to a HubSpot Marketing Event from a form (without export and import)

Phill Burrows — Tue, 23 Jun 2026 10:15:45 GMT

If you run events in HubSpot, you've probably done this dance. Someone fills in your registration form. HubSpot logs the submission. But your Marketing Event still shows zero registrants.

So you export the form fills, reimport them against the event to mark everyone "registered," then do the whole thing again after the event to mark who actually turned up.

One marketer on the HubSpot Community put it perfectly. Without automation, Marketing Events are "glorified lists."

It doesn't have to run like that. Here's how to connect a form straight to a Marketing Event so registration happens on its own. The native way, the developer way, and the way that actually holds up when you're running a lot of events.

Why this trips so many people up

In HubSpot, a form submission and a Marketing Event registration are two separate things.

The form captures the contact. The Marketing Event tracks who's registered, attended, or cancelled. Nothing automatically tells the event "this person just registered." You have to connect the two yourself.

For a long time there was no clean way to do that inside HubSpot, so teams did one of two things. They exported form submissions and reimported them against the event by hand. Or they gave up on the Marketing Event object entirely and built a custom object, because custom objects actually work with workflows and reporting.

Both are work you shouldn't have to do. Let's fix it.

The native fix: the "Add participant to marketing event" workflow action

Good news first. HubSpot added a workflow action that handles this, and most people still don't know it exists.

Here's how to set it up.

Create your Marketing Event manually in HubSpot, under Marketing > Events.
Build your registration form as normal.
Create a contact-based workflow. Set the trigger to a submission of that registration form.
Add an action. Click the + icon, open the Marketing section, and choose Add participant to marketing event.
Select your Marketing Event, and set the participant stage to Registered. You can also set attendance start and finish times later for the Attended stage.
Turn the workflow on.

That's it. Every contact who submits the form now gets registered to the event automatically. No export. No reimport. HubSpot's own guide to adding contacts to marketing events with workflows walks through the same steps.

For a single event, manually created, this genuinely solves it.

Where the native action falls short

The workflow action is good. It's also got three catches that bite the moment you scale.

It only works for events you created manually in HubSpot. If your event was synced in from Zoom or Eventbrite, the action won't touch it. That's the exact situation most webinar runners are in. The registration data lands in HubSpot through the integration, and you still can't act on it. One user described that integration as feeling "meaningless" for exactly this reason.

You build it per event. One workflow, one form mapping, one event. Fine for a couple of events a quarter. Run 20 a month and you're rebuilding the same wiring every single week. That's where the hours go.

Attendance is a second job. Registered is one stage. To mark people as Attended you need another step, usually another import or a separate sync from your webinar platform after the event. So you've automated half of it and you're back to manual for the rest.

And recurring or multi-session events get messy fast. One form across several sessions, the Zoom join link that overwrites itself every time someone registers for the next date, branching logic by session. The native action wasn't built for that.

The developer route: the Marketing Events API

If you've got development resource, there's a cleaner technical option.

The Marketing Events API lets you set a contact's participant state directly. You send the contact and the event with subscriberState set to REGISTERED, and you can reference the event by its objectId or by your own externalEventId. The calls are idempotent, so you can set the state more than once without HubSpot creating duplicate records.

It's the tidiest native path, and it works around the manual-event limitation. The catch is obvious: it needs someone who writes code, and someone who maintains it when HubSpot or your webinar tool changes. For most marketing teams, that's a dependency they don't have on tap.

How to make this automatic at scale

This is the gap we built EventEngine to close.

Instead of wiring a workflow per event, EventEngine creates a record for every single registration. A dedicated object that links the contact to that specific event and triggers your workflows on its own. It's the bit native Marketing Events can't do.

A few things change once that's in place.

Registration happens automatically from one shared form, across every event, with no per-event rebuild. It works whether the event is in person, a webinar, or hybrid. Each registration fires your workflows directly, so confirmations, reminders, and follow-up just run. Attendance feeds back too, including QR code check-in on the day, tracked straight into HubSpot.

And the data stays clean on event 50 instead of getting messier with every clone.

You configure it once. Every event after that inherits it.

The short version

If you only run the odd event and you create it manually, use HubSpot's Add participant to marketing event workflow action. It's free, it's native, and most people miss it.

If you've got developers, the Marketing Events API gives you a cleaner, more flexible version of the same thing.

If you're running real volume, pulling events in from Zoom or Eventbrite, or you're tired of rebuilding the same workflow every week, that's where a purpose-built layer like EventEngine earns its place.

Whichever route you take, stop exporting and reimporting lists. Your Marketing Events should fill themselves.

If you run events in HubSpot and the setup is eating your week, take a look at EventEngine.

Why running events in HubSpot gets harder the more you do

Phill Burrows — Fri, 19 Jun 2026 13:22:47 GMT

HubSpot is great for running and managing events. Right up until you try to run a lot of them.

The first few feel great. Forms connect to workflows, a landing page goes live, the reminder emails fire. Then you scale to 10 or 20 events a month and the whole thing quietly turns into a second job.

The reason is simple. HubSpot doesn't ship with a real events layer. It ships with the parts and leaves you to wire them together, every event, every time. Smart people stuck doing the same setup over and over.

That's why we built EventEngine. Here's where it actually breaks, and what a fix looks like.

The job nobody costed

You picked HubSpot for the automation. So it stings a bit when running events turns into the least automated thing your team does.

Every event, the same checklist. Build a registration form, then reconnect it to the right workflows. Build the workflows for signups, reminders, and follow-up. Design a landing page and get it on brand. Write and schedule the event emails. Sync everything to Zoom or Eventbrite by hand. Then test it, find the broken links, fix them, and hope nothing snaps an hour before go-live.

None of that is hard on its own. That's the trap. Each piece is a 20-minute job, and there are a dozen of them, and you do all twelve again next week for the next event.

Run the maths. 10 events a month, 2 hours of fiddly setup each, and you've burned 20+ hours before a single registration comes in. That's most of a person's week spent rebuilding things they already built in May.

Why it gets worse over time

A handful of events is fine. The problem is that manual event setup doesn't scale in a straight line. It compounds.

You hit a wall, and the wall moves toward you. Even with templates, every new event means reconnecting forms to the correct workflows, updating copy and timing and links, restyling the page to whatever the brand guidelines say this quarter, spinning up new lists and reporting properties, and re-testing the external integrations. Templates save you maybe 30%. The other 70% is still hands on keys.

Your portal turns into a dusty attic. Half-named workflows. Orphaned forms. Assets nobody remembers creating. Six months in, your team spends real time just working out which form feeds which event, and whether that workflow is safe to delete. The thing that started out tidy is now the reason onboarding a new hire takes a week.

Brand consistency slips when you're moving fast. The registration button drifts off your primary colour. A speaker section loses its formatting. A form header forgets the tone of voice. Each one is small. Put five events a month in front of three different people and the inconsistency multiplies, and now someone's spending Friday afternoon chasing design approvals on a page that should've been automatic.

The admin eats the strategy. This is the part that actually costs you. Your marketers stop being marketers and become task-runners. Copy-paste an email template, swap the details. Reconnect a Zoom link. Test a reminder sequence one event at a time. Build custom tags for this event's reporting, then again for the next one. It's tedious, it's easy to get wrong, and getting it wrong is expensive: broken links reach real attendees, wrong details go out, follow-ups fire at 3am. The team ends up spending more time fixing mistakes than they ever spent preventing them.

The integrations only go one way. HubSpot's native event handling doesn't match how people actually use Zoom or Eventbrite. You can pull data in, but you can't push changes back. Reschedule an event, change a speaker, move a session, and nothing updates downstream. So attendee data lives in three places at once, and nobody's quite sure who's actually registered. At a few events you can hold that together by hand. At thirty, you can't.

The costs that don't show up on a timesheet

The lost hours are the obvious bit. The rest is quieter and worse.

Reporting falls apart. When event data is scattered across a dozen workflows and as many spreadsheets, showing leadership a clean ROI number becomes nearly impossible. You've run 40 events and you still can't answer "did they work?" in one screen.

Collaboration gets friction. Put several people on a manual process and you get bottlenecks, version-control mess, and a round of finger-pointing every time something breaks.

Growth gets nervous. We've seen teams quietly cap their own event programme because they know the process won't take the weight. Events get delayed. Some get cancelled. The opportunity cost never lands on a report, but it's there.

And the attendee feels it. Every manual step is a chance for a registration to fail, a confirmation to go missing, or a join link to break. That's the one cost that reaches the customer.

What good actually looks like

Running events at scale should feel like a machine doing its job. Most teams we work with are surviving a fire drill twice a month instead.

In practice that means a few things. You configure it once, and that configuration powers every event after it. One registration system that behaves the same way across webinars, in-person, hybrid, whatever. Workflows that handle capture, nurture, and follow-up on their own. Page templates that stay on brand but still let you customise. A two-way sync that keeps HubSpot and your event platforms honest with each other. And a data structure that stays clean on event 50 instead of getting messier with every clone.

Done right, you stop cloning events altogether.

How EventEngine handles it

We built EventEngine for teams who run real volume and need a system that holds up, and we help you get it set up inside your own portal. It installs straight into HubSpot and gives you the event infrastructure HubSpot leaves out, the layer you've been hand-building all along.

Four things change.

You get one event framework instead of many. Rather than bespoke workflows per event, you build universal processes that adapt to the event type. Set it up once. Every event after that inherits it.

Pages template themselves. Branded page templates populate with event-specific content automatically, on brand, every time, without anyone restyling a button.

The sync goes both ways. Connections to your event platforms push and pull, so a reschedule or a speaker change flows across your stack instead of waiting on someone to remember.

The data manages itself. Attendees get tagged, segmented, and routed automatically. No custom properties hand-built per event. No cleanup later.

Stop rebuilding, start scaling

Every duplicated form is time you won't get back. Every manually reconnected workflow is an hour you didn't spend on the actual work.

And the actual work is the good stuff: lifting registration conversion, reading engagement patterns, improving your speakers and content, proving the programme's ROI to the people who fund it, and growing the thing on purpose instead of by accident.

Teams that scale events run on a system. Teams that struggle run on willpower, and willpower doesn't survive thirty events a month.

If your team is doing 10+ events a month by hand, you already know which one you're on. Worth a look at what the other side feels like.