It would be nice to have fine grained permissions on field/table level.
e.g. when you manage employees, you don’t want everybody to see also the salary information.
Hello @mwesox! First of all, welcome to Baserow 
Role-based access control is planned for Baserow 1.13, stay tuned!
@olgatrykush
I’ve been exploring the RBAC features and found that the filed level permission locks the whole column, including data entry.
Is there a way to just lock the “edit field” menu?
The idea is that in a large team scenario - there are usually users who should be able to enter data, but not change the field settings
(like adding a single select option, or change the field type).
I have to admit that this is one of the key features my team used in Airtable. It surely makes managers’ lives less stressful 
If it’s not possible yet, have you considered adding such a feature?
Hey @dev-rd, we don’t have field-level permissions yet. Currently, we support permissions at the workspace, database, and table levels, and view-level permissions are in development. Am I missing anything?
@olgatrykush I meant this:
but with more control
Oh, got it. In that case, you can define the editor roles at the table level, and those users will be able to edit the field:
Field-level permissions are a way to refine the access a user already has at the table level; they do not replace table permissions. Field permissions can only restrict editing further; they can’t grant editing to roles that can’t edit the table.
I’m an editor here and can add/modify data, but I can’t edit the field settings:
Is it what you’re looking for?
I can work with that. Thanks!
@olgatrykush maybe you could advise.
Turns out that editor role cannot create or save collaborative views or share views… While I get that this is likely by design, this renders the editor role as a very basic one, too basic for many “table tasks”.
On the other hand the builder role has too much “power” over fields.
I would really need something in-between - ideally an equivalent to editor + the ability to create/save collaborative views.
Either that OR a builder with restricted access to editing field types/names…
Thanks!
Hey @dev-rd, that’s correct — only a Builder or higher can create, edit, or delete collaborative views. You can find a detailed overview of permission capabilities here: Baserow: understand role levels
I’ll check with the team, but I’m not sure if this is something we’re planning to change. 
Hey @dev-rd, I checked with the team, and the best way to achieve what you need would be custom roles for RBAC. We’re planning to work on this feature this year, likely in Q4, possibly earlier. Here’s the issue to track the progress: Customize permissions per roles for RBAC · Issue #2778 · baserow/baserow · GitHub
@olgatrykush
That would be great, thanks!
one more question - is it possible to enable the creation of public views (shared views) from an editor role account?
If not, would the scope of such feature be more manageable than custom RBAC?
(hopefully faster to implement)
Just a thought - ideally, there would be a per-user or per-table toggle 
and admins could enable/disable that, but I understand this may be more complicated under the hood.
Hey @dev-rd, I’ll check this with the team
Hey @dev-rd, custom roles are quite high on our priority list, so we’d recommend waiting for those instead.
We want to keep the default roles fairly general, as every customer has different permission needs. Rather than adding more fixed roles or permissions that only solve some use cases, we’d rather provide custom roles so everyone can configure access the way they need.
Hope for your understanding 