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?
one solution that could fit all (since it remains our responsibility to handle the granularity): give edit permission to a user only on specific views.
So airtable’s users can prepare specific views (hide fields, use filters as needed) and give access to another user to edit what need to be edited. This “editor” would have power to edit only what is visible in this view, can not see other views, neither other tabs of the table.
one solution that could fit all (since it remains our responsibility to handle the granularity): give edit permission to a user only on specific views.
So airtable’s users can prepare specific views (hide fields, use filters as needed) and give access to another user to edit what need to be edited. This “editor” would have power to edit only what is visible in this view, can not see other views, neither other tabs of the table.
Me Too! Please for heaven sake give us some granular permission settings :winking_face: Airtable is awesome and has so much potentials but without a few fundamental capabilities its use cases are limited.
We have started testing Airtable in our organization and definitely would shift our business into Airtable if we could have some extra features, permission settings being on the top.
Thank you
We can’t have an external collaborator access tables where we keep private data (eg. financials).
Surely setting access at table level i something that can be rolled out painlessly? Or maybe not.
Here’s my contribution:
What industry do you work in? What role do you have? How are you using Airtable?
Tech, as Marketing Manager. I’ve built out a base to track programs of work, campaigns, content production and tasks. And all the financials.
Are you most concerned with view access, write access, share access, or another form of information access?
I don’t want specific collaborators to be able to access specific tables. Good if all of the above can be set for each too.
Who are you using Airtable with? With other Airtable collaborators? If so, are these other collaborators base or workspace collaborators? Or, are you using Airtable with non-Airtable users? If so, are they using forms? How are they using these forms?
1. Freelance copywriters. I can set up tables for each to keep them separate (a requirement) but would be happy to limit view of records for a single table based on their association to a collaborator. So freelancer Jo Smith can only see his / her records.
2. Developers. Same as above.
What is the nature of the information that you’re concerned about? Where does it live? In specific cells? In records? In fields? In field configurations? Just in specific views? In entire tables? In the names of records, fields, or tables? In share links?
Info lives in all of the above, of course.
Happy to have permissions set at table level.
Do you use linked records at all? If so, how would you expect that linked records would interact with more granular permissions?
Extensively.
If a collaborator does not have access to a table then I wouldn’t want them to see the linked records in another.
Just to add my use here, and hoping this will progress!
I’m using Airtable as a project management tool. We’re a small team but do involve external users on some of our bases. I’m mostly concerned with write access here, but view access is also something that would be highly useful. All collaborators are base collaborators only as we have a lot of quite different bases.
As an example, I build a base for a major event that requires links between key deliverables, tasks, and promotional content. e.g. a web page launch requires design and development tasks, but also linked to social media promotion once launched. Currently these three tables are viewable by all, but it would be useful to hide one or more depending on role - the external developer does not need to view the social content plan.
Restricting write access would also be very useful. For example, the external developer should not need to edit the fields I create for their task, but should be able to change the progress column from ‘In progress’ to ‘For review’, or check the ‘Done’ checkbox column, for example. Currently if I need anyone to do anything more than comment I need to give them the ability to edit the whole record, and trust that they will leave it alone. And as Airtable updates in real time, it’s not just about trust, but guarding against mistakes.
So what I’d love to be able to do is:
option to hide whole tables from certain users
ability to restrict ability to edit certain fields
ability to restrict records - for example, only allow users to view/edit records that they are collaborators on.
We use linked records a lot. I’d expect the behaviour either to show any that the user doesn’t have permission to view in a slightly ‘greyed out’ design with no ability to click through, or simply missing.
There currently isn’t a way to prevent a user (even at read-only) from duplicating and stealing an entire base.
Regardless of how granular permissions CAN get, that’s just totally unacceptable from a security perspective. Once discovering it, we had to move entirely off of airtable. Our bases contained information that are valuable because we pay for it and they directly relate to the bottom line. Allowing any type of user to copy the entire thing is really a critical development flaw.
When developing user experiences, the key rule is “Don’t make me think”; the bigger the manual, the greater the failure at achieving this goal. Now lets add additional systems into the mix for which Airtable is the system of record. Airtable has a nice API, but you can only read from and push to Airtable; Airtable can’t notify external systems when records are deleted. When users haven’t read the manual and delete records in Airtable, the auxiliary systems are now out of sync.
This situation will get worse over time because the initial users of the system may have it drilled into their heads not to delete records, but they’ll get promoted or leave the company and their successors may not have a good hand-off, the institutional knowledge will be lost, eventually someone will “clean up” the data in Airtable and now data within the various systems are completely out of sync.
Now you need to create a data validation system which will periodically compare data within the various connected systems to find and fix the orphans. All because Airtable doesn’t allow me to prevent record deletion.
(My primary concern is as a data integrator, I need to either prevent record deletion or be able to read a list of deleted records. Since preventing record deletion is too difficult, how about adding a filter that would allow me to retrieve a list of records in a given table that were deleted within the last x minutes?)
Me:
Software Product Designer
Small business owner
Trying to love Airtable
User need cases - based on this thread
restrict data access by users with varying levels of access needs (by field / by view / by base etc)
prevent unwanted deletion
Airtable product concerns
Keep things simple
Keep permissions from becoming barrier to productivity
Comments
Airtable rightly knows its ideal customers are likely to be non-enterprise level teams looking for simple (yet powerful) solutions. Nobody wants complicated permission groups / tiers / and layers.
Solution
Views. They currently have all the building blocks of a structured permission system.
Locked view is already a flag on a view that allows modification or not. Separate this out from “Personal” they are not mutually exclusive states.
Hidden fields. Combined with locked views, we now have granular control over both and edit permissions. (view permission already = shared links)
Now add per-user access to views. Kind of already exists with personal views, which is a single user association to a view. Now open that association to multiple users.
Finally, a user permission tier that can edit records but cannot create or alter views. Both functionalities already exist within Editor and Commenter permissions.
Finally ho’s able to configure the user to view associations? Creators only.
