How to Create Custom Views in Airtable: A Visual Guide

A grid view of an Airtable table with 30 columns and 5,000 rows is a wall of text nobody wants to look at. Views are how that same table becomes a clean Kanban board for sales, a calendar for production, a filtered list for finance, and an approval queue for management — all showing the same records, all updated in real time, none stepping on each other.

This guide covers every view type Airtable offers, when to use each one, and the filter, sort, and grouping mechanics that make views actually useful. By the end you'll be building views that earn their place rather than cluttering your base.

What Views Actually Are

A view is a saved configuration on top of a table. It decides:

• Which records show (filters)
• In what order (sorts)
• How they're grouped (grouping)
• Which fields are visible (hidden/visible toggle)
• How they're displayed (Grid, Kanban, Calendar, etc.)

Every view shares the same underlying records. Edit a value in the Kanban view and the Grid view shows the change immediately. There's only one copy of the data — views are just different windows into it.

This is the single biggest mental shift coming from spreadsheets. You don't make a copy of the data per use case. You make a view.

The Eight View Types

Picking the right view comes down to one question: what's the user trying to do? Editing data? Grid. Moving items between stages? Kanban. Spotting scheduling conflicts? Calendar or Timeline.

Grid View

The default. A familiar spreadsheet-style table. Use it for:

• Data entry and editing
• Bulk operations on many records
• Detailed inspection of all fields on a record
• Anything an admin or power user does

The Grid view's superpower is field hiding. Even on a table with 40 fields, a Grid view that hides 30 of them feels lean. Different teams get different Grid views with different fields visible. Sales sees deal-related fields, finance sees payment-related fields.

Kanban View

A board of columns where each column is a value of a single-select field. Records are cards that you can drag between columns. The drag-and-drop changes the underlying field value.

Use it for:

• Sales pipelines (Stage field)
• Content production (Status field — Draft, Editing, Approved, Published)
• Task management (Status — To Do, In Progress, Done)
• Application review (Stage — New, Phone Screen, Interview, Offer)

A useful pattern: build a Kanban view filtered to only "active" records (excluding archived statuses) so the board stays manageable. Group rules and field requirements are similar to Trello if you've used that.

Calendar View

Records placed on a calendar based on a date field. Use it for:

• Editorial calendars
• Booking schedules
• Event planning
• Anything where "when" is the primary axis

The calendar can show a single date field (the day the record represents) or a date range (showing the record across multiple days). For multi-day records, both Start and End date fields are needed.

Gallery View

Records displayed as cards, each card showing an attachment image as the main visual. Use it for:

• Product catalogs
• Asset libraries (photos, design files)
• Real estate listings
• Anything where the visual is the point

Without an attachment field with images, Gallery view falls back to text-only cards — at which point you might as well use the Grid view. Always pair Gallery with image attachments.

Gantt and Timeline Views

Both show records along a horizontal time axis. The differences:

• Gantt is built for project schedules with dependencies and percentage-complete tracking. Tasks chain together, completed work shades in.
• Timeline is a more general multi-track view. Each row is a "swimlane" grouped by a field (e.g. team member, channel), and records span time within each lane.

Use Gantt for project plans where the sequence matters. Use Timeline for marketing campaigns, roadmaps, or anything with parallel tracks of work.

List View

A hierarchical view that nests linked records. The parent record expands to show its children, which expand to show theirs. Use it for:

• Project → tasks → subtasks
• Company → departments → people
• Product line → SKUs → variants

This is the right view whenever the data has a real parent-child shape and the user needs to navigate the hierarchy.

Form View

A form that submits to the table. Public users (no Airtable account) can fill it in and create new records. Use it for:

• Client intake
• Survey responses
• Internal requests
• Anything where the response should become a record

Form view is its own beast — it's not really for looking at data, it's for collecting it. For internal forms that need login, use a Form layout inside Interface Designer instead.

For full reference, see Airtable's view documentation.

The Three Levers: Filter, Sort, Group

Every view has three controls that shape what you see. Get fluent with them and views stop feeling cluttered.

Filters

Filters decide which records appear. You build them as condition rows:

• Status is Active
• Owner is Current User
• Due Date is within next 14 days
• Total Amount is greater than 5000

Multiple conditions can be ANDed or ORed together. Most filters use AND — "show me records that are active and assigned to me and due this week."

A few high-value filter patterns:

• Current user filters for "my work" views. The Owner is Current User condition means each person sees only their own records — same view, different content per user. The cleanest way to build "my dashboard" without making per-person views.
• Date relative filters. Filters like "within next 7 days" or "is in the past" update automatically as time moves forward. No manual maintenance.
• Negative filters (Status is not Done) are usually clearer than long lists of inclusions.

Sorts

Sorts decide order. You can sort on multiple fields with priority — primary sort by Status, then secondary sort by Due Date within each status.

Sort tips:

• Sort descending on Created Time to put newest records first — useful for activity feeds and recent items.
• Sort ascending on Due Date with overdue records highlighted — useful for inbox-style views.
• Multi-level sort with a status column first makes Kanban-like grouping in a regular Grid view.

Grouping

Grouping clusters records by a shared field value. Each group has a collapsible header.

Grouping turns a flat list into a navigable structure. A typical pattern:

• Grid view of Tasks
• Group by Project (Level 1)
• Within each project, group by Status (Level 2)
• Sort within each status by Due Date

Suddenly you have an indented, navigable view that feels much more like a real app than a spreadsheet.

You can group on up to three fields. More than that gets unwieldy.

Sharing Views

Three ways to share a view:

With Airtable collaborators. Anyone with access to the base sees all collaborative views. They can switch between them freely.

Public share link. Right-click a view and choose Share view. Airtable generates a public URL. Anyone with the link sees the view in read-only mode. They can filter and sort within the share but can't edit data. On paid plans, you can password-protect, restrict by email domain, and disable copying.

Embedded view. The share link includes an embed snippet you can paste into a website, Notion page, or Coda doc. The view renders inline and stays live.

Public share links are how we deliver "live reports" to clients without giving them seats in the base. The downside: anyone with the link can see the data, so don't share sensitive information this way.

Personal vs Collaborative Views

Every view is either personal or collaborative.

• Personal views are only visible to the user who created them. Changes don't affect anyone else. They're great for "I want to see this data my way" without polluting the base.
• Collaborative views are visible to all collaborators. They show up in the view list for everyone. They become part of the base's permanent UI.

Make views personal when you're experimenting. Convert to collaborative when the view is stable and someone else benefits from seeing it.

View Patterns for Common Roles

A typical client base ends up with these views per table:

Tasks table:

• All Active Tasks (Grid, filter Status ≠ Done, group by Project)
• My Tasks (Grid, filter Assignee is Current User)
• Kanban by Status (Kanban, single-select = Status)
• Calendar by Due Date (Calendar on Due Date)
• Overdue (Grid, filter Due Date is before today AND Status ≠ Done)
• Done This Week (Grid, filter Status = Done AND Completed Date is within last 7 days)

Clients table:

• Active Clients (Grid, filter Status = Active)
• Pipeline (Kanban grouped by Stage)
• Renewals This Quarter (Calendar on Renewal Date)
• By Owner (Grid, group by Account Manager)

Invoices table:

• Unpaid (Grid, filter Status = Unpaid, sort by Due Date)
• Aging (Grid, grouped by aging bucket: Current / 30 / 60 / 90+)
• This Month (Calendar, filter Issued Date is this month)
• Paid Last 30 Days (Grid, filter Status = Paid)

Each view answers a specific question someone is asking. Build views to match the questions, not to expose all the data.

Hidden Trick: Views for Automation Triggers

Views aren't just for humans. They're also how you target automations.

Every Airtable automation that uses "When a record matches conditions" can point at a specific view. The automation fires whenever a record enters the view (matches the filter for the first time). Combine a dedicated trigger view with the automation, and you've got precise control over what runs.

Pattern:

• Create a view called Automation Trigger - Send Welcome Email
• Filter: Status = New AND Email Sent ≠ checked
• Build the automation: trigger on records entering this view, send the welcome email, set Email Sent = checked
• The record falls out of the view, the automation never fires on it again

We use trigger views for every automation. They make the logic visible (you can open the view and see exactly which records the automation will act on next) and they prevent loops.

For more on automation patterns, see our automation guide.

Common Mistakes

A few things to watch for.

Too many views. A table with 40 collaborative views is impossible to navigate. Prune ruthlessly. If a view hasn't been used in three months, archive it.

Personal views shared accidentally. A view created in someone's personal view list isn't visible to teammates. If you build the perfect view for the team and they can't see it, check whether it's personal vs collaborative.

Filter logic mistakes. "Status = Active OR Owner = Me" returns more records than intended. Use parentheses or rewrite the filter to be unambiguous: AND/OR grouping is easy to get wrong.

Hidden fields confusing the team. A new team member opens a view, sees a few columns, and assumes the table only has those fields. Document somewhere that views hide fields, and consider an "All Fields" Grid view that exposes everything for admin work.

Forgetting to sort. Views without a sort show records in unpredictable order. Always set at least one sort, even if it's just "Created Time descending."

Where to Go Next

Views work hand in hand with linked records (which let you split data across tables) and Interface Designer (which builds custom front-ends on top of view-style filtered data). Once you're fluent with views, the next leap in usability is interfaces — same data, even more curated, with buttons and dashboards.

For the official view reference, see Airtable's views overview documentation.