Updated: May 30, 2020
Ever wanted to create an Airtable app? You like to go through basics in app creation and the data model that is involved, here's some interesting content for you
About Airtable apps
Airtable is like a simple sheet to manage your content, it appears very easy. However, if you want to build a base that you can use as an application for your business, then an Airtable base has to be designed with a logical connection between multiple tables in base. Typically, this can be used across any of the small businesses and especially beneficial with data that are linked together.
There are many Airtable templates readily available, which can be easily used to quickly adapt your business use case.
You think it’s not straight forward to setup Airtable base (Project), yes it’s. We first need to design Airtable relational data model (Don’t worry about Jargons).
Airtable relational data model is created to establish a relationship between different parties involved in the system. We would like to take you through this process through a very popular Airtable use case – Staffing Management system for an Event Management Company
Often the Staffing Management system involves the following challenges:
Keep track of Candidates employment History
Candidates Job Preferences
Season after Season transfer
over old information
Jumping across platforms to review resumes of candidates and their fitment into the system
Through Airtable, a unified database is built that solved the following challenges:
Retain information on every candidate over time
Allow automating the Roster building process, which would benefit multiple teams that are co-ordinating
Bring back Outstanding workers and place them in better positions better suited for their skills
Airtable base Data Model Creation
For a simpler understanding of the AirTable Shift Management app, we need to create some tables which hold some records. Tables are logical entities that are involved in the system.
To start with For an Event Management Company, the main entity is an Event. So, we create a table with the name Events.
The Event table consists of the following information at a bare minimum:
Event Start Date
Out of above 1,2,3,4,5 – Event Name is a unique name, Event Start and end dates, Event types are unique for a particular type.
The event location is not unique. Two different events can be performed at the same location.
So, we need to create a different table to hold all of the locations that can be pointed or referenced in the event table.
The Locations table consists of the following information at a bare minimum:
We have two tables at this point – Events, Locations.
We need staff to work for the events. The staff details need to be collected. So, we create a table for staff with the following information at a bare minimum:
Staff first name
Staff last name
Staff Email Address
Staff social network details
Positions interested in work
Interviewer of Staff
Active or Not Active
Think of any other data that can be included. A Simple exercise for you :-)
We have three tables at this point – Events, Locations, and Staff.
Two different staff can be performed by the same Interviewer.
So, we need to create a different table to hold all Interviewer details that can be pointed or referenced in Staff or other tables.