ow do you all organize multiple linked bases without losing track?

Hi ​@sarahlauren0471,

Welcome to the community!

It doesn’t sound like your Airtable system is setup properly. In 99% of systems, only one base is needed.

And one base is always the #1 best way to get a fully-functional system with the best ability to scale, integrate, and automate in the future.

- ScottWorld, Expert Airtable Consultant

Before moving everything into one base, I'd look at why the data was split in the first place. The real problem is that you no longer have a clear source of truth for each part of the workflow

Pick one thing you keep losing track of, like a project, client or piece of content, and trace where it's created and where it's updated

It ight sound obvious but this will fix your entire situation

I disagree with ​@ScottWorld on this. Significant unconnected workflows can command their own bases. 

For example, assume for a 100 person company, Recruiting pipeline is significant enough to handle jobs, candidates, applications, interviews etc and can contain the entire recruitment pipeline culminating in a Team table which can have a source of truth resource used by other teams: list of all/active employees. This list can be read by other bases like the project management base etc. There’s no reason why Accounts team needs access to this base beyond the list of the team members.

Similarly, the accounting base can have products, pricing, customers, invoices etc that is used by a smaller subset of users and they can design it for, say, automating their QBO workflows. If their data remains sufficiently siloed, they only need to share maybe the list of customers to other bases. The HR team doesn’t need this.

Airtable is pushing for Interface driven use cases, and it’d be easier to implement role base access control there, if most users never use the data views. And that may be the reason why Scott suggested one base with role specific interfaces. But I do not believe Airtable ever intended single base for org workflows. One look at its record limits across pricing tiers and you’ll know why.

TL;DR: One base should support most workflows of a sufficiently independent team, while ensuring some common output that other teams can consume as needed.

Yes, I agree with ​@VikasVimal that completely different teams at a large organization can often benefit from having their own unique base that is dedicated to just their unique workflow, especially if they don’t need to interact with other teams too often. (And if they do have limited interactions with those other teams, Airtable’s “sync table” feature can frequently work great.)

What I meant in my earlier post is that when using Airtable for one particular purpose (or for one particular team), one base is almost always the best approach — so all the interfaces, automations, and external integrations have one unified place to come together.

I could sense from the original author’s post, where she mentioned “small content/project workflow”, that the one-base approach would be the best approach here. I see a lot of new Airtable users creating a new base for every new project, which would be the wrong way to go.

- ScottWorld, Expert Airtable Consultant 

Hm, could you talk a bit about the different bases and how they’re linked together, and maybe an example of an issue you’re facing with keeping track of which base owns what?

For me, the bases usually expand pretty organically and so the names of the new bases tend to fall into place on their own

I think the structure’s going to heavily depend on your workflows and how they fit with those 4-5 bases, and so an example would be helpful!

Hey Sarah,

I’m going to assume you have multiple bases for a reason and address the actual question posed 😉

You have a few options when it comes to keeping track of them.

You could have one master base that has one simple table with a few columns such as Base Name, Description, Purpose, Audience, Base URL.

You could also use the Base Guide that is accessible by clicking the arrow next to the base name in the top left of the screen: 

Another option would be to organise them into workspaces. For example, you could have a Sales workspace and any sales bases would go in there, a Marketing workspace would have their bases, etc.

I hope this helps and feel free to reach out if you have any further questions :)

Holly

One other recommendation I’d throw in here:

Don’t re-sync data downstream.

If you sync from Base A to Base B, and then realise Base C also needs the same dataset, Always sync from the origin (Base A).

When clients of ours have the same problems as you, there’s usually a tangled web of syncs that everyone has forgotten about.

Hope that helps!

Experienced Airtable users typically manage sprawling, interconnected bases by consolidating core data into a centralized "Hub" base and pushing out information to satellite workspaces using Airtable Sync rather than complex cross-base relationships. To maintain clear data ownership, teams implement prefix-based naming conventions (e.g., [Hub], [Ops], [Content]) and maintain a master data dictionary table that tracks the single source of truth for every synced table and field.

Honestly, if you're comfortable with a little scripting, you could go a step further and build an Airtable inventory base. Airtable's API lets you pull information about your bases, tables, fields and views, so you could automatically document a lot of your environment.

I don't know off the top of my head whether sync lineage is exposed in enough detail to fully map synced views, but even if that part needed some manual documentation, you'd still be able to track most of the structure automatically. 

We used to have 10+ bases that all linked together similar to this. We ended up combining them all into one new base, and used Interfaces to separate each role/permissions needs. It did take a significant amount of time to restructure, but was well worth it. If you have someone who has the capacity to dedicate the time to it, it may be worth considering.