Re: When to create a new base - guidelines? Help!
Accepted Solutions
Hey @Nicole_Alves!
Welcome to the forums!
So… this is something that companies pay people millions of dollars to determine.
Short Answer:
It depends.
But suppose you have a lot of data, unique workflows, diverse roles and teams, and a need for consolidated reporting. In that case, you should lean towards designing your architecture to scale between multiple bases.
Quick note about what's below.
Adding this after I finished what’s below.
I sat in my chair for a long time staring at the ceiling, thinking about your post before leaning forward and typing, so I just let the thoughts flow as they came.
Added with the fact that I tend to write in a stream of consciousness, don’t hesitate to continue to dig a bit further and ask questions about any part that you might be confused by or want more context to.
At the core of this, I imagine your structure like this:
One client can have multiple jobs associated with them.
A job then has a tree of dependencies:
Job ← Projects ← Deliverables ← Tasks.
Projects can possibly have different teams working on them.
So if you theoretically had a job made up of three projects, then it might look like this:
So, let’s add a new layer with this:
Taking what I diagrammed, let’s model what having your two teams split would look like.
This is where we run into a problem.
When thinking about the flow of data and its structure, an essential thing to keep in the front of mind is preserving your single source of truth.
A friend of mine on the Airtable team likes to call it the key to a Golden Dataset.
So, where does that go wrong here?
We have split data on our clients and our teams; in two areas where applicable and valid data on accounts/clients and our teams are found.
If we want to keep two separate bases for two different teams, we’ll have to find a way to preserve our source of truth for our client records and our teams.
Here’s one way to approach a solution:
After I pasted this screenshot, I realized that this might not be the most intuitive diagram in the world. I apologize if it’s hard to decipher. Let me know if that is the case, and I can refactor it a bit.
Depending on the size of your company and your teams (which from your post seems rather sizable), you can justify having bases dedicated to your employee directory and your clients.
I think there are considerable advantages to having a base dedicated to your clients.
You’d be able to keep a streamlined sales pipeline/CRM that is not attached to your production operations that might come from sales activity.
This would protect your production teams from seeing or having to interact with sales information.
They’d only ever have to worry about their workflows.
Similarly, having a dedicated employee directory base allows you to more granularly keep track of all your employees and designate them as belonging to a given division or team.
There are many additional advantages of having a dedicated source of truth for your employees. Any HR-related information such as mailing addresses, updated contact information, their direct reports, onboarding, offboarding handling, and recruiting efforts.
For the sake of this question, you’d set up views for your different divisions and use those views to facilitate synced tables to the correct production team bases, as depicted in the screenshot above.
Looking at this setup, we are left with a new problem.
I’ve worked through many workflows and projects with teams and creators in Airtable. While I’ve worked with a lot of reporting requirements, I’ve never had to think about how to implement a reporting visibility system that reconsolidates data from two bases with the same types of information.
Luckily, by creating a dedicated base for leadership, you can set up a synced table that pulls data from two (or more) sources.
From there, you can use that data however you’d like to give your leadership access to as much information on the overall sales and production pipeline as you’d like.
This is something that I would identify as being in the top five things that we’re all frustrated with regarding Airtable as a scaled collaboration and database platform.
There are ways to work with this requirement natively within Airtable, but they are absolutely not worth your stress, time, or energy. Trust me, I spent a ridiculously long amount of time thinking about this for over a year and a half.
If you’re deadset on the requirement of keeping specific record data from a role within a team, I recommend you look at a tool such as Stacker.
To its credit, Stacker is a dope tool. I use it personally, and I highly recommend it.
Hey @Nicole_Alves!
Welcome to the forums!
So… this is something that companies pay people millions of dollars to determine.
Short Answer:
It depends.
But suppose you have a lot of data, unique workflows, diverse roles and teams, and a need for consolidated reporting. In that case, you should lean towards designing your architecture to scale between multiple bases.
Quick note about what's below.
Adding this after I finished what’s below.
I sat in my chair for a long time staring at the ceiling, thinking about your post before leaning forward and typing, so I just let the thoughts flow as they came.
Added with the fact that I tend to write in a stream of consciousness, don’t hesitate to continue to dig a bit further and ask questions about any part that you might be confused by or want more context to.
At the core of this, I imagine your structure like this:
One client can have multiple jobs associated with them.
A job then has a tree of dependencies:
Job ← Projects ← Deliverables ← Tasks.
Projects can possibly have different teams working on them.
So if you theoretically had a job made up of three projects, then it might look like this:
So, let’s add a new layer with this:
Taking what I diagrammed, let’s model what having your two teams split would look like.
This is where we run into a problem.
When thinking about the flow of data and its structure, an essential thing to keep in the front of mind is preserving your single source of truth.
A friend of mine on the Airtable team likes to call it the key to a Golden Dataset.
So, where does that go wrong here?
We have split data on our clients and our teams; in two areas where applicable and valid data on accounts/clients and our teams are found.
If we want to keep two separate bases for two different teams, we’ll have to find a way to preserve our source of truth for our client records and our teams.
Here’s one way to approach a solution:
After I pasted this screenshot, I realized that this might not be the most intuitive diagram in the world. I apologize if it’s hard to decipher. Let me know if that is the case, and I can refactor it a bit.
Depending on the size of your company and your teams (which from your post seems rather sizable), you can justify having bases dedicated to your employee directory and your clients.
I think there are considerable advantages to having a base dedicated to your clients.
You’d be able to keep a streamlined sales pipeline/CRM that is not attached to your production operations that might come from sales activity.
This would protect your production teams from seeing or having to interact with sales information.
They’d only ever have to worry about their workflows.
Similarly, having a dedicated employee directory base allows you to more granularly keep track of all your employees and designate them as belonging to a given division or team.
There are many additional advantages of having a dedicated source of truth for your employees. Any HR-related information such as mailing addresses, updated contact information, their direct reports, onboarding, offboarding handling, and recruiting efforts.
For the sake of this question, you’d set up views for your different divisions and use those views to facilitate synced tables to the correct production team bases, as depicted in the screenshot above.
Looking at this setup, we are left with a new problem.
I’ve worked through many workflows and projects with teams and creators in Airtable. While I’ve worked with a lot of reporting requirements, I’ve never had to think about how to implement a reporting visibility system that reconsolidates data from two bases with the same types of information.
Luckily, by creating a dedicated base for leadership, you can set up a synced table that pulls data from two (or more) sources.
From there, you can use that data however you’d like to give your leadership access to as much information on the overall sales and production pipeline as you’d like.
This is something that I would identify as being in the top five things that we’re all frustrated with regarding Airtable as a scaled collaboration and database platform.
There are ways to work with this requirement natively within Airtable, but they are absolutely not worth your stress, time, or energy. Trust me, I spent a ridiculously long amount of time thinking about this for over a year and a half.
If you’re deadset on the requirement of keeping specific record data from a role within a team, I recommend you look at a tool such as Stacker.
To its credit, Stacker is a dope tool. I use it personally, and I highly recommend it.
