What does "Field & table editing permissions" mean for Pro account?

  1. How fine-grained is “Field & table editing permissions” listed for a Pro account?

  2. Can I restrict the ability for a user of a base (Collaborator?) to create/delete views but still be able to edit records in a view I’ve created and locked?

Because if I can’t stop my users who are allowed to enter new records from deleting forms and views that I’ve created for their use, then it’s a deal-breaker.

This support article has more info.

Locking a view only locks the configuration of the view (which fields are shown, filtering, sorting, etc). It doesn’t prevent editing of records. Locking a few is also different from the table & field permissions.

If you want to prevent users from deleting forms and views, give them editor permissions, and not creator permissions and you should be set. They will still be able to create personal views, but not delete any views you have created.

If they create a view, can it be seen by others?

Also, is there a way to hide tables/views from users so that information can be kept as “system” info. For example, they wouldn’t need to see a table of exchange rates used in calculations.

Finally, I noticed (flipping between my main account and an Editor account I created and shared a base with) that if I hit the button to open the record in its own window, even the Editor can hit a button to see hidden columns. Is there any way to restrict this as well? If I hide something from my users, I want it hidden.

I really want to stick to a table-based interface and not have to go use a separate SAS to build an app that access my table data. It’s looking like that might be the only option for multiple users using a base.

Every collaborator on a base can see everything in the base. You cannot hide tables.

Personal views can be hidden for convenience, but everyone can unhide them.

This topic was solved and automatically closed 15 days after the last reply. New replies are no longer allowed.