An Airtable exhibitor portal can collect booth information before an event and give organizers a clear readiness queue. Use miniExtensions to let each exhibitor supply its display details, staff contacts and setup requirements, while the organizer keeps allocation and readiness decisions separate.
At the fictional Harbor Makers Expo, Larch Studio plans to bring a tabletop display and a powered demonstration. Avery, its exhibitor contact, has supplied a logo but has not described the equipment. Organizer Sam needs that missing detail before confirming the setup instructions. An uploaded logo alone should not make the booth appear ready.
This design focuses on preparation after an exhibitor has entered the organizer’s process. It does not sell booths, reserve floor space or certify that a proposed installation is safe.
Before sharing externally, use an appropriate paid plan or active trial; the Free plan is for internal testing. Check your workspace-wide child-form allowance across all published extensions, including the tables and forms used here.
Define the organizer’s readiness decision
Start with a short list of what the event team actually needs: the display name, a description, named on-site contacts, setup information and any required files. Each requirement should have an owner and an explicit review result. Avoid a single checkbox that exhibitors can mark “Everything complete” while essential information remains unanswered.
The event registration guide addresses attendee registration and check-in. Exhibitor readiness has a different handoff: a company supplies several operational inputs, and staff decide whether those inputs support the assigned booth. Two people attending an event and two booths being prepared are different records.
Keep the meaning of Ready narrow: the organizer has reviewed the required preparation information for this participation. Arrival, installation inspection, payment and event admission can each require a separate confirmation.
Model participation separately from the exhibitor
- Exhibitors: Company Name (single line text), Website (URL), and Internal Notes (long text). Retain one organization record across event editions.
- Portal Contacts: Name (single line text), Email (email), and Exhibitor (linked record). This example uses one designated portal contact per participation.
- Events: Event Name (single line text), Event Date (date), and Setup Instructions (long text).
- Participations: Participation Reference (single line text), Exhibitor, Event and Portal Contact (linked records), Display Name (single line text), Booth Preference (long text), Assigned Booth (single line text), Allocation State (single select), and Readiness State (single select).
- Preparation Items: Requirement Name (single line text), Participation and Portal Contact (direct linked records), Required (checkbox), Due Date (date), Response (long text), Files (attachment), Submission State (single select), Review State (single select), Organizer Response (long text), Accepted Response (long text), Accepted Files (attachment), and Accepted On (date).
- Booth Staff: Name (single line text), Participation and Portal Contact (linked records), Event Role (single select), and Business Contact (email). Collect only contact details the event genuinely needs.
Use one Participation per exhibitor and event edition. Larch Studio’s November participation can be “HM26-LARCH.” Its five Preparation Items might be Display wording, Logo, Demonstration equipment, Arrival plan and On-site lead. Those records remain distinct from next year’s requirements.
The direct Portal Contact links on every exposed data table are deliberate. The users-table documentation requires each portal data table to link to its users table; the chain through Participation and Exhibitor is not a substitute.
Give the contact a focused portal
Choose Participations as the initial data table and Portal Contact as its user field. Add Preparation Items and Booth Staff with their direct contact links. Staff create and link the participation and its requirements before inviting Avery, so the first screen contains a meaningful checklist rather than an empty database.
Use the email-verification login setup under Users & Login → Login Fields. Each contact record should have one email address. For all private views, select Personal records only (linked to the logged in user) under Filter and Sort → Choose Records to Display, following the record visibility instructions.
Let Avery edit the supplied wording, responses, files and intended booth staff. Keep Assigned Booth, Allocation State, Review State and Readiness State staff-controlled. Show organizer feedback where appropriate without exposing internal assessments or another exhibitor’s information. Keep Accepted Response, Accepted Files and Accepted On read-only in every exhibitor-facing field configuration; exclude them from editable inline routes.
Sam reviews in Airtable. If several people later need different rights over one participation, redesign and test that access explicitly. The role-dependent field guidance cautions that child-form conditions use record values, not automatically the viewing person’s role. Adding another contact is not a complete permissions design.
Collect an answer for each preparation item
Avery opens Demonstration equipment and enters the proposed device, its stated requirements and how it will be used. The organizer reviews this information against the event’s process. Keep technical approval with the appropriate venue or specialist; the form should not calculate a safety approval from a checkbox.
For Display wording, Avery submits the desired printed company name and a brief description. Keep any accepted print copy in a staff-owned field named Accepted Display Copy (long text) on Participation. A later response should not silently replace wording that has already gone to production.
For Arrival plan, ask for a proposed arrival window and a business contact for the on-site lead. An exhibitor’s preferred window remains a request until staff communicates the actual arrangement. Avoid collecting travel documents, private itinerary details or unrelated personal information.
Use clear Submission State choices such as Not started, Working and Submitted. These describe the exhibitor’s progress. Review State can be Unreviewed, Needs information, Accepted or Waived. Staff should treat blank states as unreviewed when checking the queue.
Resolve dependencies before marking a booth ready
Sam sees that the logo and display wording are submitted, but the demonstration response lacks a useful description. Sam marks that item Needs information and writes a focused organizer response: describe the device and what will happen at the booth. The other accepted items stay accepted.
Avery supplies the missing detail. Sam obtains the necessary venue review through the event’s normal process, then records the accepted setup instruction. If the venue asks for a different arrangement, Sam updates the instruction and tells Avery what changed through the team’s chosen communication channel.
Before accepting an item, Sam manually copies the reviewed Response and actual uploaded files into Accepted Response and Accepted Files, checks the copies, and records Accepted On. These are independent stored values, not lookups of the editable inputs or attachment URL text. Changing a working upload must not change the accepted file copy. Test that behavior before use. Only after the required items are Accepted, or explicitly Waived with a reason, does Sam mark the participation Ready. Add Waiver Reason (long text) to Preparation Items if waivers are allowed. “Not applicable” entered by the exhibitor should remain a request for staff review, not automatically erase a requirement.
Readiness does not allocate a booth. Sam separately enters Assigned Booth and updates Allocation State after checking the actual floor plan. If a requested corner location is unavailable, retain the preference as context and communicate the confirmed assignment clearly.
Reopen readiness when an accepted setup changes
Suppose Larch Studio replaces the small demonstration with a larger display after review. Add a Preparation Change record rather than overwriting the accepted explanation. For a simple version, use another Preparation Item named Revised demonstration, link it to the same participation, and record the previous accepted item in a Previous Item self-link.
Sam returns Readiness State to Review needed while the change is assessed. Keep the original item’s Accepted Response and Accepted Files unchanged to explain what staff approved earlier. Review the new item into its own accepted fields. Staff-maintained snapshots preserve the reviewed version in this design; they are not immutable archival storage. The new submission should not inherit acceptance merely because its parent participation was previously ready.
If Avery leaves the company, verify the replacement contact through the organizer’s established process. Staff update the relevant direct user links and test the new access. Changing the company name alone will not reassign all the portal records correctly.
Operate a queue your team can maintain
The baseline workflow uses manual requirement creation, review, readiness updates and messages. Separate automations could generate standard preparation items or send reminders. Each would need checks for the correct event edition, contact, duplicate item and current status. A due date does not send a reminder by itself.
Before launch, use two fictional exhibitors. Confirm each sees only its own participation, checklist and staff contacts. Try an incomplete equipment response, a waived requirement, an unavailable booth preference and a change after readiness. Check that exhibitors cannot edit staff decisions and that submitted files stay attached to the correct item.
This approach works when organizers want a manageable preparation checklist with explicit human ownership. It leaves floor-plan allocation, billing, venue approval, badge issuance and on-site checks with their respective processes, while making the next missing input easy to find.


