Session-level registration

What it does

Session-level registration lets an attendee build their own agenda by picking individual sessions on the registration form, rather than just registering for the event as a whole. Each session is its own record with its own capacity, speakers, sponsors and type, and each pick creates a session registration row. There is no separate track concept on the form — restricting which sessions someone may choose is done with event passes and their Eligible sessions association.

Key facts

Sessions live on the event's Agenda tab and can be created either in the calendar view or the standard grid. A session carries session information, speakers, sponsors, session type and capacity.
Session capacity is set at Session > Capacity > Session maximum capacity. Event capacity and session capacity can be used together — that changed in December 2024, before which they were mutually exclusive.
Event capacity must always be greater than or equal to any session capacity. The validation is real and will block a save.
Session registration is switched on with Allow attendees to register for sessions in the event's registration settings (Form tab; older documentation calls this the "Website and form" tab).
Two modifiers sit alongside it: Allow single session registration only, which turns the multi-select into a single-select, and Make the session registration required, which stops someone registering for the event without picking at least one session.
At least one session has to be published and have seats free, or registration fails outright.
The registration form must contain the Sessions element from the form editor. Without it, sessions exist but nobody can see them.
Session registrations are visible two ways: all of them under the event's Registration and attendance tab > Event registration, and per-session under the Agenda tab > session > Registration and attendance > Sessions registrations.
Documented limitations, all current: the date/time format on the sessions element can't be changed and renders in US format; session order is fixed to record creation date and can't be sorted; custom attributes can't be added to sessions; the dynamic list has limited customisation options generally.
If you customised a registration form before a styling update, the Sessions element has to be removed and re-added to pick up the newer look. Editing in place doesn't refresh it.
Session capacity fields are hidden on the session form until Allow attendees to register for sessions is enabled on the parent event.

When to use / skip

Turn it on when the event genuinely has parallel tracks and constrained rooms — a conference, a training day with breakouts, anything where a room holds forty and two hundred people want in. The capacity enforcement and the per-session registration list are the whole point.

Skip it for single-stream events, webinars and roadshows. A lot of clients ask for session registration because their agenda has five items on it, then discover they've added a mandatory extra step to the registration form for no operational benefit. If nobody is going to be turned away from a session, and nobody is going to print a per-session attendee list, you're adding friction to the funnel for a nicer-looking form.

Also skip if the client's agenda is still moving. Sessions have to be published before registration opens, and the ordering constraint means late additions land at the bottom.

Configuration decisions

Whether session capacity, event capacity, or both are enforced — and if both, that the event number is set last and is the larger one.
Multi-select versus Allow single session registration only. Single-select is right for "pick one workshop", wrong for a conference.
Whether session choice is mandatory (Make the session registration required) or optional, which is really a decision about registration drop-off.
Whether session access is gated by event pass, using Eligible sessions, or open to everyone who registers.
Session creation order, because it is the display order and you cannot change it afterwards without recreating records.
Whether sessions get their own waitlists, which is configured per session and behaves differently from the event waitlist.

Gotchas

The order of operations on capacity is not obvious: set session capacities first, then set the event capacity to something at least as large. Do it the other way round and you'll get a validation error the client will read as a bug.
If the client already has a value in event capacity and needs to raise a session above it, they have to clear the event capacity, set the session, then set the event capacity again. Nobody guesses that.
Session ordering by creation date is the complaint you will hear most. Plan the agenda, then create the sessions in the order you want them displayed, in one sitting.
US date format on the sessions element is not configurable. For a UK or European client this is a visible defect on a public page and there is no supported fix — set expectations before the form goes to the brand team.
Custom attributes can't be added to sessions, so any "we also need to capture X per session" requirement needs a related table and custom rendering, not configuration.
Session capacity fields simply aren't on the form until the event-level toggle is on, so a consultant configuring sessions first will conclude the feature doesn't exist.

Consultant notes

Show the client the sessions element on a real form early, US dates and creation-date ordering included. It's better to have that argument in design than in the week of launch.
Ask the blunt question: will anyone actually be refused entry to a session? If not, don't enable it.
Agree who creates sessions and in what order, and treat it as a one-shot data entry exercise rather than something the marketing team drips in over a month.
If session access needs gating by ticket type, design the passes first — sessions and passes together have an ordering dependency on the form as well as in the data.
Check before go-live that at least one session is published with seats available, in the actual production event. It's the most common cause of a registration form that renders but won't submit.

Worth another look if Microsoft makes session ordering or the date format configurable — both are long-standing asks.