Hi, I'm new to Airtable and I'm setting up Bases for a company with multiple teams (marketing, sales, project management, asset management & finance). When I set up Bases, is it best to set up separate Bases for each team or to have one Base with multiple Tables for the entire company? The teams share data for Accounts, Contacts, Asset ID and Deal Amount, so those will be common to all and needs to be the universal source of truth. Does it make sense to have one Base with those common/shared Tables and then share and sync the Bases, or to just do it all in one Base? If I created one Base, it will end up having many Tables and could become unwieldly, but seems much easier to create automations if everything is in one Base with multiple Tables. The end goal is to have one source of truth.
Organizing Bases
+3Best answer by AirBenderMarcus
Hey @MRC
The answer really depends on your exact use case, but best practices are to centralize data as much as possible. You're right that it will be far easier to manage automations out of a single base. If your team members are allowed to see each other's records and all have really similar workflows, then I recommend a single base. You can create multiple Views so each team member can organize/filter the data how they want.
An even more dynamic long-term solution is creating an Interface on top of your data which can be configured to only show records each member is assigned to. In this way, team members can access just access the Interface (without needing access to the Base and its Tables itself) and only ever get exposed to data that is directly related to their own work.
+15Hey @MRC
The answer really depends on your exact use case, but best practices are to centralize data as much as possible. You're right that it will be far easier to manage automations out of a single base. If your team members are allowed to see each other's records and all have really similar workflows, then I recommend a single base. You can create multiple Views so each team member can organize/filter the data how they want.
An even more dynamic long-term solution is creating an Interface on top of your data which can be configured to only show records each member is assigned to. In this way, team members can access just access the Interface (without needing access to the Base and its Tables itself) and only ever get exposed to data that is directly related to their own work.
+22Hey @MRC!
I'm going to brain dump a bit here.
This reminds me of a thread from last year.
My thoughts and feelings haven't changed from what I posted in this thread.
Fracturing data is almost never the answer.
Something I would emphasize is that you should trust Airtable. Don't be afraid of large amounts of data.
People are easily frightened when their data is properly mapped into Airtable because they see a lot of tables, they see a lot of fields, and they see the number of records their data actually translates to.
The important thing to keep in mind is that your data was always that complex, you just haven't had a way to store it and organize it.
It's not intrinsic to Airtable, it's something you'll see if you put your data into any database.
Strong database structure and design will allow you to create really clean and slick views and Interfaces.
This is the core of an application. You have a consolidated, organized database. Then you create interfaces that facilitate user interactions and activities with the data in the database.
You can have a huge array of different users with varied needs and the needs of your users can be answered with the same database.
The answer isn't to create duplicates or to build a bunch of different databases. The answer is to craft UIs that support the needs of your user stories. In Airtable, those are Interfaces.
As a product, Interfaces has continued to improve (albeit slowly) and is in a much better place than it was a year ago. Airtable has pivoted heavily towards Interfaces, which means that you'll be rewarded in the mid-long term for investing your time in building Interfaces to support user interactions with your data.
+3Thanks Ben. You hit on it. Having strong Database Architecture is essential. Only then can you create, in your words, the Slick Views and Interfaces for users. It seems like what it's coming down to for me for a company of 50 users that creating one Base may be the way to go. There is not a lot of concern about sharing confidential data and in fact, project team members may need access to data that was collected during the sales process too. But I could create Views that are relevant to each team so project management team wouldn't need to see all the interactions from the sales reps leading up to a closed deal. However, some things like storyboards, quotes and other elements that might be captured during the sales process would also be used by the project team, so in an organization of this size, we're all utilizing much of the same information. And in fact, some project roles also are managing some sales deals so they need to live in both worlds. I am leaning toward one Base with multiple Tables, then getting really proficient with Views and Interfaces. This also will support Leadership because they can have a View or Interface based on the source of truth. I know that another alternative is to have multiple Bases and then share/sync Bases between teams, but that may not be necessary at this point. Thanks for helping me to think this through.
Login to the community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.