It is possible to impersonate a user while building/previewing Interfaces. Unfortunately impersonation is limited to the visibility of records, but doesn't consider the impersonee's permissions. E.g. an admin that impersonates a read-only user can still change the value of a field through an automation triggered by a button. Respecting the impersonee's permissions at least in preview mode would be very helpful for building interfaces. ... View more

The biggest issue with Airtable for me and many of my clients is that I cannot restrict viewing some sensitive data for new users. Let’s say I have a base which is serving as a CRM and CMS at once. I can’t divide it into two even with Airtable Sync. So I’m adding a new content editor for the CMS tables only and he can see all the money data of my client. This is NOT good at all. I strongly believe that this feature is needed for most professional users of Airtable. The Airtable team has added recently an ability to set editing and deleting permissions — it’s great but it’s not enough at all. Because of this Airtable is a limited tool for me. ... View more

I know that Airtable is designed to be like the friendly and convenient corner store, not like an Amazon distribution center that uses metal detectors and employs armed security guards. I love that about Airtable. But the inability to shut the doors to this convenience store is, for me and my clients, a deal-breaking problem. I wish that any (or all) of the following were possible: Creator should have option to hide the share button for all non-creator users. If creators aren’t given ability to decide who can share/not share the base, then at least read-only users should NOT have the ability to share. When I think “read only”, I don’t think “read and make a copy for all your friends and let them make copies for all their friends…”. Finally, it needs to be possible to restrict users to using what they’ve been given. To this end, should be a privileges level just below Editors called perhaps “End Users”. End Users should be allowed to edit data in records but NOT edit locked views. That is, for End Users, the “create private view” button would disappear. William ... View more

What is the proposed idea/solution? Not really 'row locking' in the database sense of dealing with simultaneous access, but rather the ability to mark a record as immutable or set certain permissions for it. Additionally -- and critically -- the ability to trigger this function through Automations. How does it solve the user problems? Enhance control over data integrity by preventing accidental modifications once a record is 'complete'; Streamline certain workflows by marking task completion; Ensure that only the right people are able to edit a record at certain points in its lifecycle, with changes to the permissions triggered by Automation, and; enable customization of data access on a per-record basis. How was this validated? User feedback expressing the desire for greater control over record modifications (which can sometimes be addressed at the Interface level with the 'Current User' option in filters, but it's not appropriate in every case and only applies to that one interface) and to prevent modifications to complete records while still being able to read the ticket in all of the normal ways (no easy way to do that from what I can tell.) Who is the target audience? Teams & Organizations managing complex workflows; Data Managers responsible for maintaining data integrity, and; Consultants & Agencies setting up systems on Airtable for their clients. This addition would bolster control over data modifications. ... View more

Issue: The Description app is handy, but it’s too easy to edit and accidentally modify. Example: when you set up a series of links as a resource, users have to click to EDIT the description in order to get a little popup that you can THEN click to open the URL. I would consider this unexpected UX. Expected Behavior: A description should be read-only unless you explicitly want to modify it. This way, clicking on it doesn’t lead to accidental modification, and a link will should just open on the first click. Suggested Fix: Add an Edit button. Adding an extra step is probably worth it in a lot of use cases where you really do just want a Description to be static most of the time. And it would make the Description app more useful as a resource, i.e. a way to share important or helpful links. ... View more

Hi, We work heavily with multiple vendors and need vendors to update a common test results base. We want to give each vendor read-write access to only tests they are responsible for. Currently this is not possible. Can you please consider adding this to you feature roadmap. BTW Jira allows for this fine-grain permissions OOB. Thanks, Kalindi ... View more

Dear Airtable team. Really simple question. Why you don’t have a function that can share view with editing function. Everyone can see and edit everything in a base if have an access (( Even Stackby have sharing view edit possibility, but you don’t. Its very big problem to use another service to do simple function. Please do it! In Reddit post What you want in 2022 in Airtable it’s mostly liked wish. ... View more

It would be really great if locked views ALSO prevented creators from adding brand new fields to that particular view. We had a problem occur today where a creator added several new fields onto one of our locked views, which then threw off another one of our processes — which entailed copying & pasting rows between tables. Once the creator added those new fields into the middle of our view, the copying & pasting of records between tables didn’t work properly anymore — because the fields didn’t match anymore. If a view is “locked”, it would be really awesome if it was TRULY “locked down” — meaning no new fields can be added to that view. ... View more

Airtable team: Please provide an option to DISABLE the public access to the DESCRIPTION of the VIEW for public shared links to views. This is a security issue. I didn’t notice this was publicly exposed. I had confidential notes in the description and didn’t know this was all exposed. At least there should be a way to disable that. There is a small “i” icon that many people who receive the shared view don’t even notice. I didn’t notice that either. While I see the benefit of having it there, we need an option to disable that. Now I have to remove the decription from there and leave it blank but that defeats the purpose because it was description for me. See picture of what I mean: … Here would be a perfect spot for a the switch to disable it if needed: ... View more