No, you did it the right way. You don’t want to split everything up into separate bases. In my personal opinion, that would be a huge mistake, and a huge step backwards.
If you split up everything into separate bases, you will start hitting up against massive Airtable limitations when you try to “sync” bases with each other, and you will cause yourself a lot of headaches.
There are a few exceptions to this rule, though:
- You might want to separate something out as its own base if you needed to gain more automations than the 50 automation limit that Airtable gives you with each base. (Of course, you can always outsource your extra automations to Make, which is more powerful & customizable anyways.)
- You might want to separate something out as its own base if you needed extra security on that one base. For example, if one of your internal teams needed full access to develop or change the underlying structure of their own base, you wouldn’t want to give them access to YOUR data layer in YOUR base, because then they could see & change EVERYTHING that you’ve built. But if you gave them their own base, they would just see their own data layer.
There might be a few other exceptions as well, but those are the 2 big ones that I can think of.
Outside of that, I think you did it the perfect way already!
Hope this helps!
If you have a budget and you’d like to hire the best Airtable consultant to help you with this or anything else that is Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld
Some folks on my team have suggested that each program should have its own app, with a master one where everything rolls up
Interesting! Are they facing any particular problems with having everything in one base? Wondering why they’d suggest it and what why they think it might be better, you know what I mean?
--
Curious what others think. has anyone else gone through this decision? Does keeping everything in one well-structured app make sense, or is it better to split things out?
Hm, if you’ve got everyone just using Interfaces while you’re managing the automations, fields etc, then having everything in one base is probably the best solution
If you’ve got various business units, all with their own workflows and wanting to create their own fields, automations etc, then this gets trickier. The main worry would be people accidentally messing up another business unit’s stuff without even knowing it, e.g. changing a single select option’s name causing a formula field to bug out
You can mitigate this if you have a Business plan by creating synced tables for each business unit, e.g. accounting gets base with the Program Budget and Annual Budget tables, and they can create whatever other tables fields etc in their own base. Changes made to those synced tables would then sync back to your main Base, with the only downside being that automations with synced tables are kind of limited. Without a Business plan, they’d either need to use those only as reference only, or you’d use scripting or a third party automation tool to sync the changes back
Another user asked a similar question in the thread below and I did a bit of a breakdown on the reasons why you may want to have separate bases there too!
