2.2Airtable bases, tables & fields
The essentials in 30 seconds
- Base → tables → typed fields: one domain, one table per entity, one strict type per field — hierarchy creates rigour.
- Field type is the core skill: select, date, currency, link, email — a well-typed field = clean and calculable data.
- Model before entering: right tables and right fields first — everything else (relationships, formulas, views) depends on it.
Ongoing mini-case — Lina models her file base in Oran
Lina creates her « Suivi dossiers » base: a Bénéficiaires table (name as text, status as select Prospect / Actif / Clôturé, email as email, submission date as date), a Dossiers table (amount as currency, deadline as date, documents as attachment). She resists the all-text temptation: each field gets its strict type. This well-typed base will serve in 2.3 (table relationships), 2.4 (formulas) and 2.5 (team interface).
Continuation of thread 2.1: Lina's base illustrates modelling — and continues in 2.3, 2.4 and 2.5.
1. Base, tables, fields, records
In Airtable, the organization is clear: a base (the equivalent of a file) contains tables (the sheets), each made of fields (columns) and records (rows). Create one base per domain — a lightweight CRM, project management, like Lina's « Suivi dossiers » — and each table represents an entity (Bénéficiaires, Dossiers, Factures). Each record is a file you can open in detail. It is more rigorous than a spreadsheet: each field has a strict type.
2. Field type, the core skill
Choosing field types is the key skill: short or long text, select (choice list) and multi-select, date, number, currency and percent, checkbox, link to another table, attachment, collaborator, email, URL, phone… A well-typed field guarantees clean, filterable and calculable data: a date stays a date (filterable « this week »), a number stays a number (summable). Mistyping — everything as text — falls back into messy spreadsheet habits.
3. Model before entering
Modelling your base well from the start — the right tables, the right fields — determines everything that follows: relationships (2.3), formulas (2.4), views and interfaces (2.5), automations (levels 3-4). Simple rule: one table per « kind of thing » managed, neither a single catch-all nor over-splitting. And as soon as information repeats from one table to another, do not copy it: link it (section 2.3). Lina spent twenty minutes on her structure before entering the first row — the best minutes of the project.
🔎 Concrete example — 🔎 Concrete example — Modelling Lina's Bénéficiaires table
Each field with the right type, as in Lina's base:
Nom → Text
Statut → Select (Prospect / Actif / Clôturé)
E-mail → Email
Budget alloué → Currency
Date de dépôt → DateReading: a structured base, ready for relationships.
Lesson: one table per « kind of thing » managed.
Section vocabulary
- Base
- Airtable container grouping linked tables around a domain (file tracking, CRM) — the equivalent of a file.
Simple example: Lina's « Suivi dossiers » base in Oran.
What it is not: an isolated sheet with no link to the others.
Reflex: one business domain = one base.
- Table
- Sheet of a base representing an entity (Bénéficiaires, Dossiers) — made of fields and records.
Simple example: Lina's Bénéficiaires table, distinct from the Dossiers table.
What it is not: a catch-all table mixing beneficiaries, files and invoices.
Reflex: one table per kind of thing managed.
- Field
- Column of a table with a strict type (text, select, date, number, link, attachment) that constrains data.
Simple example: Lina's Échéance field, typed as date and therefore filterable by week.
What it is not: a free-text column where dates and amounts mix.
Reflex: always choose the strictest possible type.
- Record
- Row of a table (one beneficiary, one file) that opens as a detailed file.
Simple example: File no. 12 that Lina opens to see the detail.
What it is not: a simple spreadsheet cell with no identity of its own.
Reflex: think file (entity), not row (cells).
- Field type
- Nature of a field that constrains and validates data: a date stays a date, a number a number.
Simple example: Lina's currency amount, summable and filterable.
What it is not: an amount typed as free text with « DA » written by hand.
Reflex: all-text = back to messy spreadsheet.
In practice — In practice — Modelling an Airtable base
- Create a base for a real domain (for example file tracking) and a first table (Bénéficiaires).
- Add well-typed fields: Nom (text), Statut (select), E-mail (email), Budget (currency), submission date (date).
- Create a second table (Dossiers or Orders) with its own typed fields.
- Enter a few records and open a file to see the detail: you have a structured base.
Ready-to-say script — framing modelling with your team (30 s)
« Before entering anything, let us list our entities: one table per kind of thing — beneficiaries, files, invoices. For each field, choose the strictest type: select for statuses, date for deadlines, currency for amounts. Twenty minutes of modelling now will save us hours of cleaning later. »
Say at project start; note entities on the board before touching the tool.
Copy-paste template — modelling sheet for a table
TABLE: _______________ (entity: Bénéficiaires / Dossiers / Factures…)
FIELDS:
- _______________ → Text / Long text
- _______________ → Select (options: ____ / ____ / ____)
- _______________ → Date | Currency | Number | Email | URL | Phone
- _______________ → Link to table _______________ (see 2.3)
- _______________ → Attachment
RULE: no all-text field by default — the strictest type wins.Small business / first CRM
Two tables suffice to start (Contacts, Deals) with five well-typed fields each — extend afterwards.
SME Algeria
Lina adds a typed Phone field and a Wilaya select for her beneficiaries in Oran and beyond.
Production management
Products, Orders, Suppliers tables: quantities as number, prices as currency, lead times as date — never as text.
Editorial tracking
Articles, Authors tables: status as select (Draft / Reviewed / Published), publication date as date, visual as attachment.
✓ Best practices
- Type each field strictly (date, select, currency…).
- Create one table per distinct entity, neither more nor less.
- Model before entering (tables and fields first).
✗ Common pitfalls
- Putting everything in free text (back to messy spreadsheet).
- Under-splitting (one catch-all table) or over-splitting.
- Copying the same info into several tables instead of linking.
Key takeaways
- Hierarchy: base → tables → fields (columns) + records (rows).
- Each field has a strict type: text, select, date, number, link, attachment…
- Well-typed fields guarantee clean, filterable and calculable data.
- Initial modelling (right tables, right fields) determines relationships, formulas and views.
48h challenge — apply tomorrow
Model one real base on paper with the template above (tables + field types), then create it in Airtable with zero all-text fields by default. Enter 5 test records.
- I can cite the base → tables → fields + records hierarchy.
- I can choose the strict type of each common field.
- I created a modelled base with 5 test records.
Frequently asked questions
What is the difference between Airtable and a spreadsheet like Excel or Google Sheets?
A spreadsheet is a free grid: any cell accepts anything, and rows are not real « entities ». Airtable is a database: each field has a strict type, each record is a file you can open and link to other tables, and you can create views, forms and automations. Concretely, Airtable avoids the chaos of « everything in one sheet »: data stays clean, linked without duplication and usable. For heavy numerical calculation, Excel keeps the edge; for structuring and linking business information, Airtable is far superior.
How many tables should you create to model well?
As many as there are distinct entities in your domain, no more. Simple rule: one table per « kind of thing » you manage (Bénéficiaires, Dossiers, Factures…). The sign of good modelling: you do not repeat the same information in several tables — you link it (section 2.3). If you catch yourself copying a beneficiary name into ten file rows, you need a linked Bénéficiaires table. Avoid both under-splitting (everything in one catch-all table) and over-splitting (tables for details that could be simple fields).
Lina creates the « Échéance » field for her files. Which type should she choose?