An Airtable call-for-speakers workflow can collect proposed sessions, organize human reviews and track the separate step of inviting a speaker. Use miniExtensions for the submission and follow-up experience, and keep each proposal distinct from its review records and eventual program entry.

Consider a fictional community conference, Practical Operations Day. Alex Rivera proposes a talk about reducing handoff mistakes. Two volunteers review the idea, the program chair asks for a narrower outline, and Alex submits a revised abstract. The goal is a clear selection trail, not simply another attendee registration form.

Start with the decision the team needs to make

A useful proposal explains the audience, what attendees will learn and how the speaker plans to cover the subject. It does not need every final production asset. Collecting slides and a high-resolution headshot from every applicant adds work before the team knows who it will invite.

Separate three states in your process: a proposal was received, the team decided to invite the speaker, and the speaker confirmed participation. A “Submitted” confirmation should promise only receipt. Do not imply a speaking slot, fee, travel arrangement or publication permission that the organizers have not agreed.

The existing event registration and check-in guide covers attendee participation. Speaker selection happens earlier and needs a different model: several proposals may come from one person, several reviewers may examine a proposal, and only selected proposals become scheduled sessions.

Use separate proposal and review records

  • Speakers: Name (single line text), Email (email), Short Bio (long text), and Organization (single line text). Store one speaker record for the intended portal identity.
  • Proposals: Proposal Number (autonumber), Speaker (linked record to Speakers), Event (single line text for this single-event example), Title (single line text), Abstract (long text), Audience (single select), Learning Outcomes (long text), Requested Format (single select), Submitted At (created time), and Decision Stage (single select).
  • Reviewers: Reviewer Name (single line text), Email (email), and Area of Interest (multiple select).
  • Reviews: Proposal (linked record to Proposals), Reviewer (linked record to Reviewers), Relevance Notes (long text), Clarity Notes (long text), Recommendation (single select), Review Date (date), and Conflict Declared (checkbox).
  • Selected Sessions: Proposal (linked record), Confirmed Speaker (linked record to Speakers), Final Title (single line text), Confirmation State (single select), Session Materials (attachment), and Production Notes (long text).

The Review table prevents one volunteer from overwriting another’s comments. The Selected Sessions table keeps production information away from unselected ideas. These tables are suggested Airtable structures, not built-in conference-management features.

For repeat events, replace the Event text field with a linked Events table. Keep the event edition on every proposal so last year’s selection does not appear to be a decision about this year’s application.

Collect a useful first proposal

Configure the submission experience around the title, abstract, intended audience, outcomes and format. Provide a short example of a specific learning outcome, such as “Participants will leave with a three-question handoff checklist.” Avoid asking speakers to upload confidential client decks or identify private customer records.

For a portal-based approach, use Proposals as the data table and Speaker as the linked user field. Follow the users-table setup documentation for the required direct relationship. Keep the public proposal fields separate from internal reviewer notes and the chair’s decision controls.

For private access, open Users & Login, select the email under Login Fields, and enable Two-Factor Authentication (Email verification). Each user record needs one valid email address, not a shared list. Follow the email-verification setup; typing a known email alone should not be your access check.

Review every exposed private table and every view: under Filter and Sort, set Choose Records to Display to Personal records only (linked to the logged in user). Follow the record-scope instructions. Keep each record linked to the actual intended user, then verify access with both fictional users.

A one-off proposal can instead use a form, with staff reconciling the submitted contact to an existing Speaker record. Do not expose a list of every applicant’s email as a convenience picker. If you later provide direct editing links, the record-editing guide explains the supported form setup. Decide deliberately who should possess those links and which fields they may change.

Let reviewers evaluate the same submitted version

Before distributing work, the program chair checks for duplicate submissions and assigns review records. Alex’s original proposal receives two separate Reviews. Each reviewer records their reasoning and recommendation, leaving the final selection decision with the chair.

Use a defined review cutoff or retain a staff snapshot of the submitted abstract in a separate long-text field before review starts. If speakers can keep editing their abstract, reviewers may otherwise evaluate different versions. This snapshot is a manual workflow choice; the suggested schema does not implement automatic version control.

When a reviewer declares a conflict, the chair reassigns the work instead of treating a blank recommendation as a negative vote. Store the reason for reassignment in an appropriate staff-only place and avoid publishing unnecessary personal details.

Reviewers and speakers should not share an undifferentiated editing surface. miniExtensions’ guidance on different fields for different users notes the limitations of conditions when records link to multiple user types. For this example, keep review work in Airtable or build a separate reviewer portal with its own tested relationships and access rules. Hiding a field in one form is not the entire access design.

Record the decision and ask for confirmation

The chair compares the two reviews with the program’s needs. Suppose both reviewers like Alex’s example but think the proposed scope is too broad. The chair records “Revision requested” and a concise speaker-facing request: focus on handoffs between two teams and include one worked example.

Keep the original review evidence when the revision arrives. Record a revision date and note which revised abstract the chair accepted. If the revision materially changes the talk, obtain whatever further review your program requires rather than silently carrying the old recommendation forward.

Once the chair decides to invite Alex, record Invitation Sent separately from Speaker Confirmed. Send the invitation through the organizers’ chosen communication process. A table update alone does not deliver it. Only after the reply is received should staff confirm the slot and create the Selected Sessions record.

Now request production assets: final title, short bio, headshot and presentation file if needed. Keep the requested deadline explicit and store the latest accepted materials deliberately. Permission to submit a proposal should not be treated as permission to publish every uploaded item.

Test the awkward cases before opening submissions

  • One fictional speaker submits two different proposals. Both remain linked to the same speaker without merging their reviews.
  • Two reviewers add comments to one proposal. Neither review overwrites the other.
  • A speaker revises an abstract after review starts. The chair can identify what each review was based on.
  • An invited speaker declines. The proposal remains historically invited, but no confirmed session is announced.
  • A speaker logs in while a reviewer logs in separately. Verify each can access only the intended records and fields.
  • A confirmation message accurately says that the proposal was received, without suggesting selection.

This is a practical fit for a small program team that wants organized submissions and accountable human decisions. It does not provide blind-review guarantees, conflict detection, automatic agenda optimization or a full conference platform. Start with a process the chair can operate manually, then add notifications or assignment automation only when the underlying review rules are clear.