Teams, Bases or Tables for my sole propriety?



First off, wonderful product, really, it’s wonderful!
Now I just want to use it correctly.

I am launching a local landscape design service. I want to use Airtable from the beginning, so I want to make sure I use the teams, bases and tables correctly.

Since I am a one person operation who contracts out the build of my designs?

I want to incorporate every facet of my business into Airtable, from contracts, legal & lic., suppliers, products, clients, accounting, etc. So should I treat the facets of my business as separate teams, bases, or tables?


Since you’re just a one-man operation, you can probably fit all the aspects of your business in a single team. One of the main reasons a single business might split their operations among several teams is due to permissions concerns. Luckily, as a one-man operation, you shouldn’t have to worry too much about other, unauthorized employees having access to confidential data. :slight_smile:

Whether or not to split up the facets of your business into different bases, well—that’s ultimately up to you, although I personally would recommend trying to fit everything into a single base, at least at first.

Based on what we’ve seen, some people like to have different facets in different bases because it allows them to keep certain things which don’t have a whole lot to do with each other separate. The disadvantage of this, however, is that you can’t use the powerful linking features (and the associated field types like rollups, lookups, and count) across different bases. You may also have to end up repeating data if you split it over multiple bases, which can cause problems.

The Product Catalog template has a pretty good demonstration of how you can fit clients, suppliers, products, and orders into a single base spread out over multiple tables (this support article also has an explanation of how/why the tables are arranged the way that they are). The nonprofit ScholarMatch also runs their entire nonprofit off a single base—you can read this case study to find out how.

If you’re not sure, I would generally recommend starting with a smaller number of bases (perhaps just one, even), then, if you need to, you can split existing bases into multiple bases. This is a lot easier than consolidating many bases into a single base later, in my opinion!


I had tried all three approaches and found that the linking wasn’t possible from base to base or team to team.
Will a future release have expanded linking?


Linking across bases is definitely something we are putting a lot of thought into implementing (though I can say that it’s unlikely that it’ll be implemented within the next few months). This thread has a lot of lively discussion about linking across bases, and the challenges therein.


Thanks for the link,
I saw your question in there asking why users would want base links. I
think all 3 would be good reasons, but personally the third option about a
cramped base i find true, in both the desktop and Android versions. Needing
to scrub to the left to view each table will give lazy people a chance to
act lazy, and require admins to answer lazy questions. Horizontal tabs will
extend table names beyond the screen. So wanting to link between bases in
my cases was undertaken to clean up the UI, only to find out its not

Side note, the old music making software called reason by propellerheads
had a unique module linking gui. Something similar could be useful for
visualizing our schema. Records can be plugged into other tables and you
can select which jack to plug it into, for example read only, editable,
needing approval, formula.

Just some thoughts