You can manage conference session preferences in Airtable by collecting attendees’ ranked choices separately from the sessions an organizer confirms. miniExtensions provides the attendee-facing form or portal; Airtable holds the session catalog, preference records and final assignments. This works well when a conference team wants a reviewed agenda rather than instant seat booking.

Imagine a fictional one-day professional conference with two morning time slots and several parallel workshops. Morgan prefers “Practical Reporting” at 10:00, with “Data Cleanup” as a second choice. Both sessions are popular. The organizer needs to understand that preference without telling Morgan a seat has already been reserved.

Separate interest from a confirmed agenda

A session preference answers “What would you like to attend?” An assignment answers “Where should you go?” Keep those answers in different records. Otherwise, a participant changing their first choice can accidentally alter what the team considers the final schedule.

Use three operational stages: collect preferences, review capacity and conflicts, then publish confirmed assignments. Explain the preference deadline and when attendees should expect their agenda. The statuses and review process described here are your workflow design, not a built-in booking engine.

Create records for people, sessions and choices

Start with the following Airtable tables. Keep the example limited to adult attendees and ordinary scheduling information.

  • Attendees: Name as single line text, Email as email, and Registration reference as single line text.
  • Time Slots: Slot name as primary text, Start and End as date fields with time enabled, and Event day as a date.
  • Sessions: Session title as primary text, Time slot as one link to Time Slots, Room as single line text, Description as long text, and Planned capacity as an integer number.
  • Preferences: Preference label as primary text, Attendee as one link to Attendees, Session as one link to Sessions, Rank as an integer number, and Submitted at as created time. Use one record per choice.
  • Assignments: Assignment label as primary text, Attendee and Session as their respective single linked records, Status as a single select with Proposed, Waitlisted, Confirmed and Withdrawn, and Organizer message as long text.

Add lookup fields on Preferences and Assignments for the linked session’s time slot. A coordinator can then group choices by attendee and slot in Airtable. Planned capacity is a planning number; merely storing it does not enforce a limit.

Give attendees a focused preference workflow

A Form suits a short preference collection step. A Portal becomes more useful when attendees need to revisit several choices and later read their agenda. The Form and Portal comparison explains those presentation differences.

For a Portal, use Preferences as the Data Table and its Attendee link as the User Field. Create the people and relationships first, then configure the intended login fields. The Users Table guide describes this relationship-based setup. Check that new preference records are associated with the correct attendee and cannot be reassigned through an editable identity field.

Present session title, time, room and description before asking for a rank. Explain that rank 1 means first choice within that time slot, not first choice across the entire day. A useful first version accepts two choices per slot and lets the coordinator flag duplicate ranks during review. Do not describe that convention as automatic validation unless you have separately configured and tested enforcement.

You can make the session picker easier to navigate using its linked Time slot relationship. In the linked-record field’s Filter section, enable Dynamic filtering and configure the relevant filter fields. The dependent dropdown documentation explains the supported linked-record relationships. A shorter picker is a navigation aid, not a seat reservation.

For each personal-data view, check Portal Tables, Views, Filter and Sort, then Choose Records to Display. Select Personal records only (linked to the logged in user). Configure login separately; a display filter is not identity verification. Review linked catalog fields too: participants should select existing options, not create or edit sessions, roles or locations through those fields.

Review a full-session case without losing the second choice

Suppose Practical Reporting has 20 planned places and 24 first-choice requests. The organizer applies a stated allocation policy, records the confirmed attendees and puts the remaining people on the waitlist. Morgan receives a Waitlisted assignment for that workshop and a Confirmed assignment for Data Cleanup in the same slot.

Keep Morgan’s original preference records. They explain why the alternative was selected and remain useful if a space opens. Before promoting Morgan, the coordinator checks whether Morgan still wants the first choice, confirms capacity and withdraws the conflicting alternative assignment. Make those changes deliberately; promoting one record alone can leave two confirmed sessions at the same time.

A second reviewer or a simple daily reconciliation can inspect attendee/time-slot groups for more than one Confirmed assignment. Rollups or formulas may support that review, but this design does not promise atomic capacity locking or prevention of simultaneous oversubscription.

Publish the confirmed agenda separately

Add Assignments to the attendee Portal using its own Attendee relationship. Provide a Confirmed agenda view and a separate Waiting or proposed view so participants can distinguish instructions from possibilities. Use predefined Portal views to select the relevant Airtable views, retaining personal-record behavior.

Make the assignment’s expanding form read-only for attendees. The whole-form read-only setting is available under Actions. Treat change requests as a separate coordinator conversation or request record. Emailing an agenda or notifying someone of promotion requires a separate communication process; this model does not send those messages automatically.

Check the agenda before using it at an event

Use fictional attendees in separate test sessions. Confirm that each sees only the intended preferences and assignments, that attendee actions cannot change capacity or confirmation status, and that a waitlisted session never appears as confirmed. Exercise a full session, two choices in one slot, a withdrawn assignment and a promotion that replaces an alternative. Reload and inspect the exact Airtable records after each change.

These are recommended acceptance checks, not tests performed for this article. This approach suits a team willing to review allocations and communicate changes. For instant ticket sales, payment handling, guaranteed inventory locking or a live on-site registration system, evaluate purpose-built event tooling instead.