Hide/Show tables and create views for each different team/department in the company

Hi,
I’ve been very interested to improve the efficiency of using Airtable. I wish we could use different bases for each department in the company but most of the work is getting done on one big (lots of tables) base. Hence, I am trying to find a good workaround. right after I saw the new ‘personal views’ section which is pretty cool, I started thinking about two things: being able to have the same feature for each department and being able to hide/show the tables.
ex: we create a table in a separate base that holds the name of the collaborators and the departments they belong to. then we sync it with the main base. when we set up a department/group view, the views we added to the list will be shown by the people who work in that department only. In the meantime, if we can have (like edit permissions feature for the fields) ‘hide’ feature and we can select the departments which don’t need to see the selected table (when ‘select all’ is used, it’ll be hidden to everyone, when ‘remove all’ selected it’ll be shown by everyone).
I am still learning, so please advise if there is an exciting feature that I can workaround. Moving some tables to the other bases cause us to make lots of changes/updates on the API that we use to pull/push/link data from/to Airtable and, since syncing table feature is one-way sync, to make them both way synced might cause the same problem which is having lots of tables in the main base.
thanks in advance, sorry for the typo.

Hi @Orhan_Baran,

This is an interesting and, truthfully, complex problem. I’ve set something up very similar in Airtable. This involved mapping out the work flow and process first, something I highly recommend, then building the bases and tables to support. There are a few variables that will significantly impact your work flow map and ultimately, your bases and tables.

  • How many users do you have that will directly use Airtable and where is there overlap? This can be seen by mapping out the various types of users, what data they need to give and receive.

  • How do users interface with the data?

  • What type of reporting needs to happen and where?

  • What does data integrity look like, meaning what data needs to be protected from other users changing it? This is more to protect from the inadvertent change or mistake.

There are obviously more questions that can be asked, this is a start. If you would like, I’m happy to discuss this further with you. Reach out anytime.

Chris