Suppose you manage a group of contractors and need to find out who's available for upcoming events.
You could send everyone a spreadsheet with the upcoming dates and ask them to enter Yes or No. That works with a small team, but becomes difficult to manage when you have more contractors and events.
In Airtable, I would structure this using three tables: People, Events, and Availability.
Create the three tables
Start with a People table where each record represents one contractor or team member. This table can include Name, Email, Role, Phone, and other information about that person.
Next, create an Events table where each record represents one event, project, booking, or shift. This table can include Event Name, Start Date, End Date, Location, and Status.
Finally, create an Availability table that connects People and Events.
Each Availability record represents one person's availability for one event. For example, one record can link Sarah to Event A with a Status of Available, while another can link Sarah to Event B with a Status of Unavailable.
The Availability table can include Person linked to People, Event linked to Events, Availability with options such as Available, Unavailable, Maybe, and Pending, plus fields such as Submitted Date and Notes.
This gives you a many-to-many structure where one person can respond to many events and one event can have responses from many people.
Collect availability with a form
If your contractors don't use Airtable, a form is probably the easiest way to collect their availability.
Create an Airtable form connected to the Availability table and include the Person, Event, Availability, and Notes fields.
Each form submission creates a new Availability record.
You can also prefill the Person and Event fields in the form URL. Instead of asking Sarah to select herself and the event, you can send her a link where those values are already filled in.
She only needs to choose Available, Unavailable, or Maybe and submit the form.
This is especially useful if you're sending availability requests by email.
Create the Availability records yourself
Another approach is to create the Availability records before asking your team.
For example, if you have an upcoming event and want responses from ten contractors, create ten Availability records linking each contractor to that event and set their Availability to Pending.
You can do this manually or automate the process if you regularly need to create many availability requests.
As responses come in, change each record from Pending to Available, Unavailable, or Maybe.
See who's available for an event
Once the responses are in Airtable, create a view in the Availability table filtered to the event you are planning.
You can then group or filter those records by Availability.
For example, filtering where Event is Event A and Availability is Available immediately gives you everyone who can work that event.
You can create another view for Pending responses if you want to see who still needs to reply.
Let team members update availability through an Interface
If your contractors or team members already use Airtable, you can also create an Interface where they update their Availability records directly.
The Interface can show the upcoming events relevant to them and allow them to change their Availability without working inside the full base.
Interface-only collaborators can be given access to an Interface without access to the underlying base on paid Airtable plans. They still need an Airtable account.
For external contractors who don't already use Airtable, I would generally keep things simpler and use the form approach instead.
Add a calendar if dates matter
If you want to see availability on a calendar, add the Event's date to the Availability table using a Lookup field.
You can then create a Calendar view based on that date and see availability records across your upcoming schedule.
For example, you could filter the calendar to only show records where Availability is Available or Confirmed.
This gives you another way to see who is scheduled around particular dates without changing the underlying structure.
Why use a separate Availability table?
You could add contractors directly to the Events table, but that only tells you who's connected to an event.
It doesn't give you a good place to store each person's response.
The Availability table lets Sarah be Available for Event A, Unavailable for Event B, and Pending for Event C while keeping all three responses separate.
You can also add more information later, such as Notes, Submitted Date, Confirmation Status, or Assigned Role, without changing your People or Events tables.
For this type of setup, I would start with People → Availability ← Events and collect each person's response through either a form or an Interface.