Again running into issues with not having more granular control of User Permissions. Wondering if this is on the Roadmap and if so (Though I know you can’t say when) is it one of the higher priority items?
what exactly you’re organizing with Airtable (cattle? marketing projects? job applicants?)
I think that a common(ish) application would be KPIs for teams, franchises, etc.
For example, as a manager, I want my teams to be able to add and edit “records” to their own “views” but not see or edit the records from other teams and views in the same “base.” However, I also don’t want to create a separate base for every team because then, as leader, I can’t take advantage of what Airtable does so well: collate and organize data, in this case, across teams. Also, if I go the “form” route, then my teams can’t update or edit KPIs without doing the whole form over again and then asking me to delete the incorrect record.
In summary, perhaps adding edit permissions for 1) views and 2) tables would be a practical and understandable way to implement more granularity.
I would like to use it for a project tracker, where I’d like financial rollup data to be hidden for certain team members. A view/table based permission set would easily solve my issue.
Column permissions solves at the core this issue. It would simply display or be hidden on views and if in a given table. Setting permissions per column takes more work to set up, but gives a high level of confidentiality and flexibility. Table permissions makes it simpler for entire tables (no need to do columns).
This is super important to us.
I would implement:
Managers/Admins with one or more Permission Groups made up of users who can be assigned to one or more groups. Where Managers/Admins, Groups or users can be assigned to Table or Column permissions where View, Edit, delete privileges can be set.
I’m aware that User Permission is a HUGE topic to cover, but one use we’d like for it (a fairly easy one, from our perspective) is to limit access to certain ‘views’ per user. This doesn’t even have to be ‘user role’ related in the meantime.
If Airtable made it possible to say:
“Ready To Print SilkScreen - Calendar View” is ONLY accessible to Admins (account owners - by default) and only specific user accounts (that an admin adds), this would save us from having our views be super cluttered with 20+ different views (seen by all).
Then, specific users on our team would be able to have a view that’s personal to them only, and they would NOT have to name the views something strange in order to differentiate where their favorite view is.
Since you asked, the user permissions that would be useful to my team include user-level customization for Tables, Fields and Views. For each, I’d love to have the same permissions options we have for Bases (Hidden, View Only, or Can Edit). It would also be useful if Users could be assigned to roles/groups, from which they can inherit these permissions. Otherwise, keeping track of this much granularity could become impossible.
That said, I want to offer a round of applause to the AirTable staff, who regularly push back against “mission creep” for this product. We all (naturally) want Airtable to do everything, but if it gets bogged down in complexity, nobody wins. Keep up the good work!
I am wondering if it is going to be possible to restrict users so they can View, Edit, and Delete only their own records, the records THEY have entered into the base. Thank you!
I have great database which manages data for a youth camp. A form collects the basic registration data for each student. Additional tables are for staff data, dorm/cabin assignment data, and “family group” data.
I don’t what everyone with editing permission to be able see all of the student data, which is confidential. I want users to be able edit only specific views of the student data. For example, one view is “check in”. I want my users to be able to see that view, find the student on the alpha list and click the check box.
I want them limited only to that view. So…we need view-level permissions for read only or edit only.
The ability to restrict View/Read/Write permissions to certain tables is critical for our use case. We have records (including sensitive personal information) on our staff located in several different countries. We need to be able to grant HR staff in one country write access to staff in their country, but NOT view/write access to records in other countries. At the same time, we’d like to create a centralized tracker that allows global leadership to view (but not write) KPIs from each country, based on those staff records. As a result, we can’t just create separate bases for each country, since you can’t link to records in different bases.
This situation would be solved if we could do one of two things:
Link to records across different bases
Set permissions at a table, rather than a base level.
It seems like accomplishing one of the two points above would account for the bulk, though obviously not all, of the cases listed above.
Adding my voice to this. I have a language academy and want to store student and employee information but not let all employees see all student fields nor employee tables. Now it’s mid 2017 so might I ask whether this is forthcoming. If not I have to use FileMaker though I’d really rather not.
