2.5Views, interfaces & sharing
The essentials in 30 seconds
- One source, several views: Grid, Kanban, Calendar, Form — same data, different angles, zero duplication.
- The interface protects and guides: mini-app on the base for the team — never deliver the open engine.
- Sharing is finely tuned: public form, team interface, read-only view — everyone sees what they should see.
Ongoing mini-case — Lina delivers the mini-app to her team
Final act: Lina turns her base into a mini-application. She creates the useful views (Kanban by status, Calendar by deadline, filtered « En retard » view from her formulas), builds an Interface with a dashboard (charts + filtered list) for the team, opens a public form to collect new requests, and sets sharing: the team sees the interface, the partner sees only a read-only view, nobody touches the raw base. The Level 2 project is delivered.
Epilogue of thread 2.1-2.4: Lina's base becomes a business application for her team.
1. Views and Interfaces
Like Notion, Airtable offers several views of the same table — Grid, Kanban, Calendar, Gallery, Timeline, Form — each with its filters, sorts and groupings, without duplicating data. But Airtable goes further with Interfaces: true mini-applications built on top of the base, with pages, charts, buttons, entry forms and navigation. You thus offer the team a guided experience without giving access to the raw base.
2. Separating data and experience
This separation is essential: data stays structured and protected on one side, the end user interacts with a clear interface on the other. Giving access to the raw base exposes the whole structure and internal mechanics — with error risks (deletions, unintended changes) and confusion. The interface shows only what is useful, guides entry and protects data. It is the difference between delivering the open engine and delivering a car with a dashboard.
3. Sharing finely
Manage sharing and permissions finely: read-only shared views for a partner, public forms (Form view, with required fields and conditional logic) to collect data, interfaces reserved for the team to steer. Result: the base becomes a small business application — dashboard, entry portal, visual tracking — usable by people who never opened Airtable. For personal use the base suffices; as soon as there are end users, the interface is required.
Did you know?
The best base is the one users never open.
🔎 Concrete example — 🔎 Concrete example — Lina's tracking mini-app
Data on one side, experience on the other, as with Lina:
Base (tables + relationships) = protected
Form view → collect (public, required fields)
Dashboard interface → charts + filtered list (team)
Read-only view → share with a partnerReading: a business application without exposing the base.
Lesson: an interface as soon as there are end users.
Section vocabulary
- View (Airtable)
- Filtered and sorted display of a table (Grid, Kanban, Calendar, Gallery, Timeline, Form), without data duplication.
Simple example: Lina's Kanban by status and Calendar by deadline.
What it is not: a copy of the table for each use.
Reflex: new angle = new view, never new table.
- Interface
- Mini-application built on an Airtable base: pages, charts, buttons, forms, guided navigation.
Simple example: The dashboard Lina's team uses each morning.
What it is not: the raw base open to the whole team.
Reflex: end users = interface, not direct access.
- Form (Form view)
- Public or internal entry view feeding the table directly, with required fields and possible conditional logic.
Simple example: Lina's new file request form.
What it is not: a free email to re-enter by hand in the base.
Reflex: collection = form with required fields.
- Sharing & permissions
- Settings defining who sees and edits what: read-only view, public form, reserved interface.
Simple example: Lina's partner sees only a read-only view.
What it is not: the full-edit link sent to everyone.
Reflex: check who sees what before each share.
- Business application
- Tool oriented to the end user (dashboard, portal) built on structured data.
Simple example: The file-tracking mini-app delivered by Lina in Oran.
What it is not: a true public app with user accounts (see level 5).
Reflex: fast internal = interface; public product = app builder.
In practice — In practice — Building an interface and sharing cleanly
- Create several views of a table (filtered Grid, Kanban by status, Calendar by date) according to uses.
- Build an Interface: a dashboard page (charts + filtered list) and a detail page.
- Add a form (Form view) to collect data, with required fields.
- Set sharing: form public, interface reserved for the team, read-only view for a partner.
Ready-to-say script — presenting the interface to the team (30 s)
« Here is your dashboard: you see current files, deadlines and delays there, without touching the base. For a new request, use the form — required fields guarantee clean data. The base stays protected: you steer with the dashboard, not with the open engine. »
Say while showing the projected interface; keep the raw base off-screen.
Copy-paste template — base sharing plan
VIEWS: filtered Grid _______________ · Kanban by _______________ · Calendar by _______________
TEAM INTERFACE: dashboard (charts + _______________ list) + detail page
FORM: Form view _______________ (public / internal, required fields: ____)
SHARING: team → interface · partner → read-only view _______________ · raw base → _______________ (restricted)Small business / solo
Two well-filtered views suffice before any interface: build a mini-app only if others use it.
SME Algeria
Lina trains her team in twenty minutes on the interface — nobody needs to learn Airtable.
Field collection
Public mobile form to report information, with required fields and closed selects.
Towards a true app
If the interface reaches its limits (external public, complex logic), move to Glide, Softr or Bubble (level 5).
✓ Best practices
- Build an interface as soon as there are end users.
- Separate protected data (base) and experience (interface).
- Tune sharing finely (public, team, read-only).
✗ Common pitfalls
- Giving access to the raw base (errors, deletions).
- Confusing internal interface and true public app (Bubble/Glide).
- Collecting via a form without required fields.
Key takeaways
- Airtable offers several views (Grid, Kanban, Calendar, Gallery, Timeline, Form) without duplicating data.
- Interfaces are true mini-apps (pages, charts, buttons) built on the base.
- Separate protected data (the base) and user experience (the interface).
- Sharing is finely tuned: public form, team interface, read-only view.
48h challenge — apply tomorrow
Build one dashboard Interface on your base (charts + filtered list) and a collection form with required fields. Have the interface tested by a colleague who never opened Airtable.
- I can explain why the raw base is not given.
- I can build views, interface and form.
- A colleague used my mini-app without training.
Frequently asked questions
Why not simply give access to the base rather than creating an interface?
Because giving access to the raw base exposes the whole structure (all tables, all fields, internal mechanics) to users who do not need it — with error risks (deletions, unintended changes) and confusion. An interface shows only what is useful, guides entry, protects data and offers a clear experience. It is the difference between delivering the open engine and delivering a car with a dashboard. For personal use, the base suffices; as soon as there are end users, the interface is required.
Can an Airtable interface replace a true application (Bubble, Glide)?
For many internal needs — dashboards, entry portals, team tracking — yes, the Airtable interface suffices and avoids adding a tool. Its limits: it stays tied to the Airtable ecosystem, with less advanced customization and business logic than a true app builder. As soon as you target a public, highly customized application, with user accounts and complex logic, move to Bubble (full web) or Glide/Softr (mobile app from a base) — this is the subject of level 5. Rule: Airtable interface for fast internal, app builder for the finished product.
Lina must have requests entered by colleagues who do not know Airtable. What does she build?