Views have no fewer capabilities for limiting who can access than Tables. In Airtable, visibility is either everything (all tables, all views) or nothing (you literally can’t open the base). Meaning, just because you put “Department B’s records” in another table doesn’t mean they are prevented from looking at Table 1 anyway.
Accessibility in terms of editing is controlled based on the field. For both Tables and Views you can say “Only Department A can edit these fields, only Department B can edit these other fields”. Accessibility in terms of creating new records is controlled at the Table level.
So you could use one table and say “only people in Department A can create new records. Only people in Department B could edit the appropriate fields for the records already there”.
That doesn’t sound specific enough. If Record A from Table 1 has a checkmark, update which records in Table 2? Every record? Are your records linked together?
There are multiple entries in my Table 1. I also have a column named Approved. There are some entries which will be Approved (checkbox is checked with a tick mark if approved). So now, if the entry which I entered now, is Approved, the I want to print its primary key and some other columns automatically in Table 2.
It is a work flow. Department 1 (Table 1) approves and pushes the info to Department 2 (Table 2). Department 2 inputs some other information and pushes to Department 3 (Table 3). So I want a separate table for each department.
Typically, it is advised that “The same info” be kept in one place, one table. Moving the same record into several tables adds many points of potential human error, plus you’re eating up limited Automation Runs you get per month.
Using filtered views, however, is how Airtable is designed to work in instances like these. Table 1 would have a view called “Department A” and would have a filter applied where the checkbox is empty and would only have the fields Department A needs to fill in visible. Once the checkbox is filled in it would be filtered out of that view automatically. Conversely, Department B would get their own view that is filtered to where the checkbox is filled and would have the additional columns visible.
Views have no fewer capabilities for limiting who can access than Tables. In Airtable, visibility is either everything (all tables, all views) or nothing (you literally can’t open the base). Meaning, just because you put “Department B’s records” in another table doesn’t mean they are prevented from looking at Table 1 anyway.
Accessibility in terms of editing is controlled based on the field. For both Tables and Views you can say “Only Department A can edit these fields, only Department B can edit these other fields”. Accessibility in terms of creating new records is controlled at the Table level.
So you could use one table and say “only people in Department A can create new records. Only people in Department B could edit the appropriate fields for the records already there”.
In addition to all the excellent guidance that @Kamille_Parks gave you above, you might benefit greatly from taking my free Airtable training course, which covers the concept of views in depth:
