Once you have your core project plan created in multiple tables in Airtable (see my previous article on how to do create a basic project plan template in Airtable), you now have your Projects, Deliverables, RAID logs, Decision logs, Action logs and similar space for all your projects. If you haven’t populated these tables yet, it is fine, there is time for that.
The next step right now is to learn how to create Views in Airtable and how you can use them in your project plans.
Views in Airtable turn your structured data into focused workspaces for managing one project at a time, running multiple projects in parallel and producing clean updates without duplicating information. Airtable works best when you treat it as a single source of truth and use views as your lenses. You absolutely don’t create separate spreadsheets, separate tables or dozens of duplicated views to see the same work in different ways. Instead, you create one single set of tables containing all your projects and all of their project information, then you create one basic View for each table that you re-use for all projects.
A good analogy for this is your Spotify. You create many many playlists and sometimes add the same song to more than one playlist. When you do this, Spotify doesn’t copy and paste the actual song into many different locations again and again. The song lives in one place, and appears in many playlists. This is how Views should be in your Airtable base. All information should live in one base, and in one table. No duplication, no copy-pasting. Then you create a View which pulls any information you want and displays it.
The next essential step is learning how to use views.
At this stage, when you open your tables, you’ll probably see a long list of rows with no clear structure. If you’ve added records for multiple projects, this can quickly become confusing and unhelpful. Nothing is wrong with your data. What’s missing is views. Views are how you tell Airtable what you want to look at right now.
What is a view in Airtable?
A view is a filtered and organised lens on the same underlying data.
- It doesn’t create a copy of your data
- It doesn’t remove or change records
- It simply shows you a subset of information based on filters, sorting, and visible fields
Instead of staring at everything at once, views let you focus on one project, one risk set, or one decision list at a time.
Your first example: Deliverables by project
Let’s start with the Deliverables / Workstreams table.
When you open it, you’ll likely see deliverables from multiple projects mixed together. Now we’ll create a view to focus on a single project.
- Go to the Deliverables / Workstreams table
- On the far left side, click Create new view
- Select Grid
- Name the view: Project – Single (manual filter)
- On the right-hand horizontal bar, click Filter
- Add condition: Project → is → select the name of a project (for example, “Client A – Data Platform”)
- Add sorting: Due date → ascending
- Hide any fields you don’t need for day-to-day work
Now, instead of a generic list, this view shows only the deliverables for the selected project..
Applying the same idea to the RAID table
You can repeat this exact pattern for risks, issues, assumptions and dependencies.
- Go to the RAID table
- Create a new view → Grid
- Name it: Project – RAID (manual filter)
- Add filters: Project → is → select the same project. Status → is not → Closed
- Add sorting:Impact → Critical to Low
This view becomes your project risk dashboard.
Each time you change project context, you change the Project filter.
Caution is needed here: don’t create too many views
The examples above are shown so you understand how views work. However, if you create:
- Separate views for every project in your program or portfolio
- Separate views for every scenario you want to see
- Separate views for every variation you want to see
You will quickly end up with dozens or even hundreds of views. In a master programme or portfolio with many projects, this becomes unmanageable and counterproductive.
How to use Airtable Views
The efficient and scalable way to use views is:
- Create one reusable “Project – manual filter” view per table
- Change the Project filter when you switch context
- Avoid creating permanently named views for each individual project
This approach gives you one clean master system, fast project switching, a setup that scales from one project to many. When you are actively working on one project, this becomes your working project plan.
When you switch to another project, you simply change the Project filter. You reuse the same view every time. You don’t create a new view for each project.
In fact, we won’t even use this method because we will ultimately automate all of this. But for now, you can apply this simple rule: One view per table, then change the rules of the filter to switch the views.
A few guidelines to keep in mind:
Don’t create One Airtable app per project, One table per project, One view per table per project
We create one single structure for all projects, one view for each table in your project structure, use that view and change the filter to show a different project depending on which project you’re focusing on each day. We never create a new table to “see things differently”. We create a new view. We never create a new view for each different scenario. We simply change the filter conditions of a single view per table.
Once you understand views, Airtable stops feeling overwhelming and starts working like a proper project control system.