What it does

The event registration experience is a real-time marketing form, built in the same form editor as any other, that carries event-specific elements: the event's name and description, the speaker list, the session list and the pass list. You choose where it lives — hosted by Microsoft, embedded in the client's site, or wrapped in a Power Pages portal.

Key facts

• Two forms ship out of the box: Default registration form and Default registration form with sessions. Both come pre-wired to a default configuration covering target audience and matching of existing records; you edit them in the normal form editor.
• Four hosting routes are documented: a standalone page hosted on Customer Insights infrastructure (no extra licence), embedded into the client's own website, a Power Pages portal built from the event registration template, or the client's own domain using the supplied out-of-box web application. There's also an event API for a fully custom front end.
• The domain has to be authenticated in Customer Insights - Journeys before it will work externally. If it isn't, the form doesn't render and submissions are rejected — no error the marketer will understand.
• One form can serve many events. The readableEventId parameter in the page URL tells the form which event it's rendering, so you don't need a form per event.
• Event-specific elements sit under Events in the editor: the sessions element, the passes element and the speaker/description content that fills itself from the event record.
• Form prefill and CAPTCHA validation are both optional toggles on the form. Prefill only works for known contacts arriving through a personalised link.
• Custom fields that don't map to a Dataverse column are supported: short text, long text, option set (dropdown or radio), multi-select checkboxes, two-option radio, number, checkbox, and date & time.
• For unmapped fields the logical field name is the key that carries the submitted value into journey orchestration. Several fields can share a logical name across different forms, but only one instance per form. The display name must be unique if you save the field for reuse, and saved fields are shared across the whole organisation.
• Responses to unmapped fields show up under Registration and attendance. The system view holding them is created on first submission and can take up to two minutes to appear.
• Registration forms are subject to Dataverse service protection API limits. Every render, session list fetch, speaker list fetch, sponsor list fetch, capacity check, CAPTCHA call, payment call and submission is an API call, and the form page is not CDN-cached.
• Event passes plug into the same form. Each pass carries a name, a Number of passes allocated (zero hides it, which is how you do VIP or draft passes), a price in the org currency, and an optional Eligible sessions association. Payments are switched on per event from the Passes tab, with providers configured under Settings > Event management > Payment providers.

When to use / skip

Use the hosted standalone page for anything internal, low-volume, or where the client has no web team. It's free, it works, and it takes about an hour. Embed the form when marketing owns a decent website and cares about the URL and the surrounding brand.

Reach for the Power Pages portal only when the client genuinely needs an authenticated, multi-event, browse-and-book experience — a conference with a hundred sessions and returning delegates who want their own agenda. It's a separate product with its own licensing, release cadence and support boundary, and plenty of clients ask for it, get it, then use it as a single-page registration form.

Configuration decisions

• Hosting model: standalone hosted page, embedded, Power Pages, own web app, or API. This decides who owns the front end for the life of the solution.
• One form per event versus one shared form driven by readableEventId. Shared is far less maintenance but constrains per-event branding.
• Whether existing-contact matching creates, updates or blocks — and whether registrations also create leads (the toggle for that lives on the event's Form tab, not the form).
• Which custom fields are unmapped (captured for this form only) versus properly modelled on contact or a custom table because someone will report on them.
• Prefill and CAPTCHA on or off. They pull in opposite directions: prefill wants a frictionless known-visitor path, CAPTCHA wants proof of a human.
• Whether passes and payments are in scope, which drags in a payment provider and developer work rather than configuration.

Gotchas

• Unauthenticated domain is the number one cause of "the form was working in preview and is blank in production". Preview doesn't exercise the domain check.
• Unmapped field values are not columns. Nobody can build an Advanced Find on them the way they expect, and clients who assumed they'd get a nice reportable field will be unhappy after the event, not before.
• Service protection limits are per environment, not per form. A big public on-sale moment, with sessions, speakers, sponsors, capacity checks and CAPTCHA all enabled, generates several calls per page view. Turn off the elements you don't need before you go on sale.
• If passes and sessions are both on the form, the passes element has to sit above the sessions element, because pass selection filters which sessions are offered. Get it the wrong way round and attendees see sessions they can't actually book.
• A pass with zero allocated is hidden from the form, which is the intended way to stage a pass — but it also looks exactly like a broken pass to a marketer who set the number later.

Consultant notes

• Do the domain authentication in the first week of the project, not the week of launch. It needs DNS changes and the client's DNS is always with a third party.
• Demo the shared-form-plus-readableEventId pattern to anyone talking about "a form per event". It usually saves them a maintenance headache they haven't imagined yet.
• Be explicit with the client that unmapped fields are for capture, not analytics. Get the list of "fields we will report on" agreed and model those properly.
• Before a high-volume on-sale, run a load sanity check with the exact element set you're shipping, and have the marketer's contingency plan for a throttled form written down.
• If Power Pages comes up, price it as a separate workstream with separate licensing and say so in the first conversation.

---

Worth revisiting when the event API or the out-of-box web application gets a documented versioning story — that's the current weak spot for custom front ends.