An Airtable attendee substitution workflow can collect a proposed replacement against an existing registration while keeping the current attendee unchanged until an organizer approves and applies the change. miniExtensions supplies the request form or portal; the event team verifies the request, follows its transfer policy and updates the actual attendee list.

Consider fictional Harbor Design Forum. Alex can no longer attend and would like colleague Morgan to take the place. The organizer needs to identify the registration, check whether substitution is allowed and coordinate the replacement details. Editing the attendee’s name immediately would make an unreviewed request look like a confirmed transfer.

Keep the registration and the proposal separate

Use these proposed Airtable tables and field types for an adult professional event:

  • Events: Event name as primary single-line text, Event date as a date and Substitution instructions as long text.
  • Attendees: Attendee name as text and Email as an email field. Keep this ordinary contact information separate from credentials or sensitive records.
  • Registrations: Registration reference as text, Event and Current attendee as linked records, Registration state as a single select and External registration reference as text.
  • Substitution requests: Request reference as text, Registration and Requesting attendee as linked records, Registration reference supplied as text, Proposed attendee name as text, Proposed attendee email as email, Request notes as long text and Requested on as a date.
  • Substitution requests, organizer fields: Review state as a single select, Organizer feedback as long text, Verified by as text, Verified on as a date, Applied on as a date, and Previous attendee and Replacement attendee as linked records to Attendees.
  • Substitution requests, completion fields: Registration update reference as text, Confirmation sent on as a date and Exception note as long text.

For registration HF-106, Current attendee remains Alex while request SR-021 proposes Morgan. The proposal is a separate record. If a second request arrives for the same registration, staff can compare them before deciding which one, if any, to apply.

Do not collect payment-card details, identity documents or unrelated personal explanations in this example. Request notes can simply describe the operational request. The organizer’s own event policy determines which substitutions are allowed and whether additional steps are needed.

Choose a request route appropriate to the event

For a small event, a standalone miniExtensions Form can collect the supplied registration reference and proposed attendee details. Keep Registration unlinked until staff matches the reference to an existing record. A typed reference or email address does not itself verify that the person may change a booking.

For repeat attendee access, use a Portal with Substitution requests as its Data Table and Requesting attendee as the User Field. The Users table guide explains the required direct link. Staff can prepare a request record for the relevant registration, allowing the attendee to provide the proposed replacement details without browsing other registrations.

Use verified login following the email verification documentation. For each private view, go to Portal Tables, choose the table, then Views and its view. Under Filter and Sort, choose Personal records only (linked to the logged in user). The personal-record guide describes this setting.

Keep Registration, Requesting attendee, review decisions and completion fields outside the attendee’s editable inputs. Do not expose the Attendees table as a public picker for selecting a replacement. Collect the proposed contact details on the request and let the organizer match or create the correct attendee record after review.

Review the request before applying a replacement

Suggested Review state choices are Received, Verification needed, Policy review, Approved to apply, Applied, Declined and Withdrawn. These are custom operational labels. Approved to apply means the responsible organizer has decided to proceed; Applied means the actual registration update has been checked.

The organizer first matches HF-106, checks its event and current attendee, and reviews other open requests for that registration. They verify the request through the event’s established process and record Verified by and Verified on only after completing that check. Login or possession of a reference is not a substitute for any additional authority checks the event requires.

Next, check the applicable substitution conditions and communicate the outcome. If the request is missing information, place a precise question in Organizer feedback rather than guessing. If a fee or separate ticketing process is required, complete that step through the proper system before claiming that the transfer is finished.

Apply the change once and preserve the previous attendee

Before applying an approved request, re-read the current Registration. Confirm that Alex is still Current attendee and that no other organizer has already substituted someone else. A saved approval does not make this multi-record operation atomic; the coordinator must reconcile conflicting updates.

Record Alex in Previous attendee and the verified Morgan record in Replacement attendee. Then update the Registration’s Current attendee deliberately. Check the saved result, record Applied on and add a useful Registration update reference. This is a manual organizer workflow, not an automatic cross-table transfer configured by the form.

Do not overwrite Alex’s Attendees record with Morgan’s name and email. Alex may have other registrations, and the original contact record explains the earlier booking. Likewise, do not copy private notes from the original attendee into Morgan’s record merely because the registration is changing.

If an external ticketing service is the authoritative system, update and verify the substitution there under its supported process. Use External registration reference to find it. Changing Airtable alone does not invalidate an old ticket, issue a new QR code, transfer payment or synchronize the service.

Keep applied requests stable and handle reversals explicitly

After review, remove the request from editable attendee views. The record-editing restriction guide explains disabling expansion and editing in a history view. Check every other available view, creation and unlinking route before treating the record as read-only for the requester.

If Morgan later cannot attend, start a new request against the current registration rather than rewriting SR-021. If the first request was applied incorrectly, leave an Exception note explaining the correction process and preserve the prior facts. The event team decides and verifies any reversal; the form should not silently restore the old attendee.

Send confirmation through the event’s normal communication channel after the authoritative attendee list and any ticket are correct. Record Confirmation sent on when that communication actually happens. Saving a date in Airtable does not send a message.

Check the attendee list before event day

Test a permitted substitution, an unknown registration, two simultaneous requests and a declined request. Confirm that submitting or declining a request leaves Current attendee unchanged. For the portal route, test two attendees and all editable views. These are recommended checks, not observed runtime results.

The event registration guide covers the broader registration experience. This workflow focuses on a controlled change to an existing registration, preserving who requested it, who approved it and which attendee is actually expected at the event.