A session is a scheduled item in an event program, such as a talk, workshop, panel, or another item attendees choose and attend. Each session has its own start and end time. It can also include a track, type, one or more speakers, and, when the event sells access by session, its own capacity and fees.
Sessions, Functions, and Other Events
An event’s Portal schedule can show more than sessions. It can also show functions, such as ticketed meals and social events, plus course offerings.
The schedule can also include other events, which are timetable items that are not sessions, functions, or courses. Examples include a golf outing or an exhibit hall opening. An other event has its own name, start and end time, location, order, and description, and it appears on the Portal schedule alongside sessions. Unlike a session, it does not include a track, type, speakers, or session-level registration.
Use a session when the schedule item needs one or more speakers attached. A function can also appear on the schedule, but registrants buy a function ticket for it instead of choosing it alongside its speakers the way they do with a session. If a course offering needs to participate fully in meetings and event reporting the way sessions do, consider setting it up as a session instead of a course.
Choosing and Ordering Sessions
When attendees build their own agenda, they choose sessions or functions during registration. There is not a separate feature for agenda building.
Rhythm warns a registrant during registration when two chosen sessions overlap. That scheduling-conflict message is built into the registration form, is not configurable, and cannot also show session end times.
Sessions, functions, and other events each have their own Display Order field, which you set when you edit the item. For functions, see Functions for where that field appears. The number places an item among other items scheduled for the same date and time, both on the schedule and in the list a registrant chooses from. Before Display Order existed, the schedule fell back to alphanumeric order, so the only way to influence how same-time items sorted was to rename them with numbers or special characters. Use Display Order for same-time items now instead of relying on naming tricks.
Session Times and Time Zones
A session’s start and end time show in the event’s time zone when the event has one. Choose that time zone by its full name, such as US/Mountain, rather than an abbreviation such as MST. When an abbreviation-based time zone was used, session times appeared an hour later on the session 360 and registration pages than what was configured, while the full name has not shown that problem.
Arizona and Phoenix do not observe daylight saving time. When the event time zone was set to US/Arizona, US/MST, or America/Phoenix, registration and other event-facing session times appeared as though daylight saving time still applied, which made them an hour off from what was configured. As a temporary workaround, some customers have set the event’s time zone to Pacific time so session hours display correctly for a Phoenix-area event. The tradeoff is that the Portal labels those times PST instead of Arizona or Mountain time.
When an event turns on the option to convert all times to the event’s time zone, session times on the Portal schedule are intended to show in the event’s configured time zone instead of each viewer’s device time zone.
Session IDs
A session’s saved ID depends on how it was created. A session created directly on an event gets an ID that defaults to the session’s name. A session created from an abstract gets an alphanumeric ID instead. Keep this in mind when you match a session’s ID to its title in a report or integration.
Deleting Sessions and What Sessions Protect
When staff delete an event, Rhythm also removes that event’s sessions, tracks, fees, and other events. Rooms and session places work differently. If the event still has active session places or rooms in use, Rhythm blocks the event from being deleted until those are cleared.
Deleting a setup record that a session uses also works differently. Rhythm will not delete a session type, track, room, speaker, speaker type, abstract, or waitlist process while any session still refers to it. If Rhythm refuses to delete one of these records, update or remove the reference on the session first instead of trying to force the deletion.
Unlike some other setup records, a session does not have one overall switch that deactivates it while leaving it visible on the schedule. To stop new registrations without deleting the session, use its capacity, places, or fee settings instead.
Presenter Access in the Portal
A person listed as a speaker on a session may be able to edit parts of that session from the Portal, without staff making the updates for them. This access depends on the event’s abstract settings, whether the event’s edit deadline has passed, and whether the person is a co-presenter when the event excludes co-presenters from editing. After the deadline passes, a presenter cannot edit the session, even if they had access earlier.
Managing a session’s documents in the Portal uses a separate permission from editing the session details. Each permission has its own switch and deadline in the event’s abstract settings, so a presenter can be allowed to manage session documents without editing the session itself, or the other way around.
Speaker profile updates are also checked per session. Because a speaker profile is not tied to just one session, the same person can have different access for different sessions, depending on each session’s settings and deadline.
Session Merge Fields in Templates and Emails
Event templates and confirmation emails can pull in session details with merge fields. The session description merge field outputs the full description. There is no way to hide part of the description so only one portion appears in a merge-only context. There is no fixed limit on how many session merge fields you can include in a template’s iteration block for repeating session data.
Inside a repeating block such as {{#each registration.sessions}} ... {{/each}}, refer to a session’s own fields directly, for example {{description}}, rather than a fully qualified field like {{session.description}}. A top-level event field, such as {{event.start_date}}, is out of scope inside that loop and will not resolve there. Format a date from within the loop using the session’s own date field instead.
Updating Sessions in Bulk
When you use Mass Update to change a boolean session field, such as Disable Portal Registration, across many sessions at once, the checkbox control may not apply the change. Enter the value as a literal expression, TRUE or FALSE, where the checkbox does not work.
Example
An event lists a keynote as its opening session, with two co-presenters. The event’s abstract settings give presenters an editing window that ends one week before the event and exclude co-presenters from session editing. The lead presenter can update the session description until that deadline. The co-presenters cannot edit the session at all, even before the deadline, because the event excludes co-presenters from that access. After the deadline passes, none of them can edit the session further, and staff handle any remaining changes.