Why bother using multiple tabs to organize data when you can use one massive tab and create multiple Views?


Something I haven’t been able to figure out is since Airtable’s Views, filter, group and sorting functions are so powerful, what’s the point of building out multiple tabs? Doesn’t that just make things more needlessly complicated?

Just add all your data to one massive tab, then filter out what you don’t need and create a different View for each use case.

I’m using Airtable to manage my content strategy, so right now I have one tab where the primary field is the post title, then all sorts of data in the columns to the right, and I have another tab where the primary field is the URL, then to the right, there’s the post title and a bunch of other data. I did this initially because I wanted to take advantage of the linking across tabs features, but you can pull data from the primary field of the tab you’re working on, so it seems a bit pointless now.

Am I missing something?


If all you need is a spreadsheet, then you may very well not be missing anything.

Multiple tables (tabs) come into play when you need to model relationships between entities or pieces of data. Those relationships allow for aggregation of data in ways that are easier to model if you are using sepearate tables to represent discrete “things”.

If you do a search for some topics in the forums with key words like “linking records” or “rollups” I’m sure you’ll run across people’s use cases for modeling relationships with multiple tables.


I feel like I know what you mean, and I feel like there is a way Airtable can help but this is all so abstract…

I do have a ton of different types of data that I want to be able to organize, analyze and co-relate, but I’m not a data scientist, I’m a writer, so I can’t figure out the best way to approach laying it all out in Airtable.

Some of the discrete things I want to organize:

  • Every blog posts, landing page, downloadable asset on the site
  • Links between posts
  • Anchor text interpost hyperlinks are embedded in
  • Keywords each post are ranking for
  • Organic traffic each post is getting

I didn’t know where to begin, so I just started building out multiple tables. I wonder if someone can take a look at what I’ve built here and let me know if I’m overcomplicating things.


It looks like you are going in the right direction. The Content, Team and Keywords tables all seem relevant and well structured. The Published URL and Good Blogs tables look like they are unnecessary duplications; this data can remain in the Contents table and be dealt with using Views.

In general you should try and think about the entities that you are working with and how they relate to each other. If two different types of entity have a one to one relationship then they probably don’t need to be stored in different tables. For example, you might decide you want to store photographic assets in your base. If your photographic assets are only ever used in one blog post then you would probably choose to just upload them as attachments in the Content table. However, if your photographic assets often get re-used across different blog posts, you would be better to store them in a Photographic Assets table and then link them to the Content table.


Thanks for the feedback David. Does Airtable have an easy/effective way to merge the data on Content and Published URL tabs in?

Regarding entities, the pages/blog posts will have many relationships with each other.

Eg. Post A links to Post B and C, then post B may link to post A and page D, and so on.

Would you say the best way to organize and internlink blogs/pages with eachother be to have on table where they all live, and then link a column to the primary field on the table? That’s how I’ve set it up.


If you can find a way to sort and filter the two tables so that the records are directly aligned then you can just copy and paste the data from the old table into new columns in the new table.

“Would you say the best way to organize and internlink blogs/pages with eachother be to have on table where they all live, and then link a column to the primary field on the table? That’s how I’ve set it up.”

That sounds like a good way to do it.