Help

Save the date! Join us on October 16 for our Product Ops launch event. Register here.

Re: When to create a new base - guidelines? Help!

Solved
Jump to Solution
2933 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Nicole_Alves
4 - Data Explorer
4 - Data Explorer

What are the reasons you would create an additional (new) base for your company’s info rather than store it in another table? We have a lot of info to track but I’m struggling with when to know what belongs in the same base, and what calls for its own base.

For example, we have 2 separate production divisions that handle the same kind of work, just on different types of accounts.

  • Clients
  • Jobs per Client
  • Projects per Job that can utilize different internal teams
  • Deliverables for each project
  • Tasks that add up to the delivery/completion of a Deliverable

Regarding the users…

  1. There is a leadership team above these divisions with the need to see data from both divisions rolled up into one place. This makes me think Division A and B’s work should all happen in the same base.

  2. For the most part, the team members within each division are not shared with the other division (although this could change in the future). For this reason, I tend to think Division A and Division B should be in their own respective bases.

  3. Another factor to consider is the diverse roles within the teams, this is mostly significant when thinking about sensitive/financial info that certain roles need to track, and that we would not want other roles to be able to see. This challenge makes set up particularly complicated given that we can’t just hide a table or columns from certain people.

Any tips/suggestions on how to set this up?

Thank you!

1 Solution

Accepted Solutions
Ben_Young1
11 - Venus
11 - Venus

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:

image

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:

image


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.

image


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:

image

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.

See Solution in Thread

5 Replies 5
Ben_Young1
11 - Venus
11 - Venus

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:

image

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:

image


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.

image


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:

image

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.

My two cents on the topic of portals:

There are several competitors to Stacker, which I feel offer much better value and are much easier to use. These include MiniExtensions.com, GlideApps.com, Softr.io, and Pory.io.

It doesn’t matter. :slightly_smiling_face: You had me at the second diagram. One of the best answers ever in the history of community responses. Love the visuals - great answers.

Wow, great reply. I would like to subscribe to Ben Young’s Daily Musings.

Hi Ben,
Thank you so much for offering your expertise here. This has been very helpful to kickstart us in the right direction. Thank you, thank you, thank you!! :raised_hands: