My question is: In this scenario, should each SR project schedule be its own base that feeds into a single Calendar, Roadmap, PMO Metric Report, etc.?
Hmm this depends on how you're planning on using it?
Some good reasons for breaking it into different bases might be:
1. You've got a dataset that multiple departments might need to use (e.g. a Client list) that only specific people should be able to modify. And so you'd put that data into a different base and sync it over to other bases or use it as a data library: https://support.airtable.com/docs/data-sets-and-verifying-data-in-airtable
---
2. Different teams might have very different ways of working, and you might want them to have the freedom to make modifications to the base structure themselves without messing up other team's workflows or going through you to make changes
- This is somewhat mitigated by using Interfaces for this and allowing each team to have their own Interface that's private to them. They'd still be making changes to the base structure though, which might be confusing in the long run to other team members who have access to the same base. And you'd need to give them Creator permissions to the base and so they'd be able to accidentally modify / delete fields, formulas, automations etc. If not, every change would need to go through you, which might be a good thing depending on the desired workflow?
And so if each SR project schedule's going to be managed by a team of people and they're going to be using Airtable to work, then it might be worth considering giving them their own base with strict instructions on how you expect data to be formatted so that you can do proper reporting. They'd format it the way you want in a separate table and you'd just sync it over to your reporting base track milestones, create the roadmap view etc
If this is just going to be a small team of people using Airtable then I wouldn't worry about this overmuch and would just keep everything in one base though
---
3. Record limits! Each plan comes with different record limits per base; the Teams plan comes with 50k records per base, while Business comes with 125k, Enterprise 500k. If your workflow involves say, logging a lot of data and consolidating it, then it might be worth considering separating that out from the get go and creating a system to handle that
As an example, I know someone who needs to log every Shopify order they ever get so that they can deal with shipping details on a per order basis. As such, we created a base that just logged said orders, and created a table that would consolidate those order details (e.g. # orders in last week, last month, etc), and then synced that table to their main working base
This allowed them to keep using their main base to do their work, and when the orders logging base ran out of room we just duplicated it to keep the historical data and then deleted all the records
