[IN DEV] Entity-level permissions

Party time!!! :partying_face::partying_face::partying_face::partying_face:

That is SO great!! Well done :blush:

*Studies screenshots in detail… * :eyes:

Looks good. As promised, every entity you can choose which level you share it at…

Question: does it mean that if I share a Space with Pete, Angela and Chao… (everyone gets Contributor permissions in the space)…

That I get to set the permissions for each entity within the space…

  • Entity A - Viewer: Angela, Pete. Owner: Chao.
  • Entity B - Viewer: Angela, Pete.
  • Entity C - Owner: me (so none of these 3 chumps gets any access)
  • Entity D - Viewer, Angela, Pete, Chao.

… and that if I have a map View, people only see the entities that they have at least Viewer access to, and that in any other View the same is the case, they do not see where they do not have permission.

Or do I even not have to share the Space with people, I only need to share at least one entity for them to see the space with that entity?

And if so and if there are documents within that Space, do they see those? And all the Views? (with only this Entity?

And what if an Entity they do not have access to is referred to in a document?

Wondering. Thanks for your great work again you spoil us!! and have a good weekend!

OOOoooOOOOoo! I’m a brand new fibery user. I read through the permissions model you’re looking to implement and I think it’s incredible. So excited for this!! Can’t believe you’re already this far.


great that this makes ways…

from the screenshot i are that i can on an entity level GIVE permissions. but is it also possible to retract permissions on a single entity?

if a database has access given to all members for example, but o want to take a single entity private?


I was wondering that too!

Looks good to me. Just deploy that sucker to production RIGHT NOW​:+1::grin::joy:

1 Like

It seems like there are lots of questions, and tbh, I don’t think we will answer them all :stuck_out_tongue_winking_eye:
Not because we can’t, but because it makes most sense to wait for the first beta release, when we can not only say what is and isn’t possible, but also how to do things in practice.
Suffice it to say that prior to starting implementation we tried to consider a whole load of use cases (not just specific features/functions) and we think that what we will eventually deliver will make a lot of people happy (or at least satisfied!)
We haven’t planned for permissions control at the field level (and maybe never will) but almost everything else that has been asked for has been considered.


Ok good point :smile:


Will wait and see! :innocent:

And haha permissions on field level, that is really fine grained.

Btw must be a (fun) challenge to design and build a tool that is so flexible and that can be applied for so many things!

1 Like
  1. You don’t have to share Space with people, only entity you want them see. If you give access to the whole Space, it will work as today, they will see all entities. However, you may still give more wide permissions to some exact entity. Imagine you gave Viewer access to CRM space, but also gave Editor access to one Customer X. In this case a user will be able to see all customers, but edit only customer X
  2. If you do not give access to Space, all docs and views will be hidden from a user.
  3. Access will propagate through relations eventually. For example, you have a Project with many Tasks, so when you give access to a Project a user will also have the same access level to all Tasks. It will not be in the first release, but quite soon. As for references, I don’t exactly remember what we decided.

That was not planned. Any use case you have in mind?

actually, that is one of the main things i hope you implement :smile:

Contact management is an example where in general i want to give access to all contacts in the database. but sometimes there is a private contact that referred a contact. i want to add that information for myself, but I don’t need everyone to get these private phone numbers and email for example.

also emails that I sync to fibery would be a good example. my company account gets synced and in general all these emails are good to be read by everyone. but sometimes there is a conversation i want to set private.

i guess there are a lot of examples where a database is shared in general and only some entities need privacy where this “set as private” setting would make sense instead of the other way round …

thanks for asking!


I am hoping that the Entity Locking feature will be part of this permissions implementation with automation rules?
The idea is that a lot of content in an organization is time-sensitive, e.g. financial entries or meeting minutes, or other reasons why editability is rule-based.


Thank you for the clarity! :ok_hand:

It is taking shape


The new permissions model looks great!

If this can eventually also be applied to Views then we would have 80% of “field-based permissions”, since we could expose our sensitive DB fields only in certain Views, which could then be permissions-restricted.

Multiple entity views would complete the picture :grinning:


We do have plans to Share Views (via new permission model), but not this year for sure. However, in this shared view a visitor still can open some entity and see more fields, so it is not enough to just have that, we should add Entity Views to make it work for your case.


My thought was that any “sensitive” fields could simply be hidden in entity view.
But it’s even better to make the entire entity view subject to permissions as well :+1:

1 Like

Awesome! :muscle: It’s looking great! :heart_eyes:

Thanks for the update!

Awesome! :heart_eyes:

We also have several GDPR use cases on contact level that are currently a pain in the ass. Would be awesome if this can be fixed in the future via new permissions model :partying_face::partying_face:

1 Like

This is really exciting development and looking forward to trying it out.

However, similar to @Matt_Blais & @YvetteLans , I am hoping we are able to get to be able to have some field level controls, even if it is through creative means. I posted Setting field/UI properties based on conditions request with a proposal on this front. It is nothing new that hasn’t been discussed in some form in other posts, but I thought this might be a good time to bring the ideas together again since there is renewed discussion on permissions and how information is presented in the UI.


Unfortunately, we will never implement field-level permissions due to tech. limitations. The only viable workaround that will work — create some additional Database, move all fields you want to hide there, and use 1-1 connection between this database and original database. Thus you will isolate fields, but editing will be not very easy, always extra-clicks…

For example, you may have Employee database and want to hide Salary. In this case you will have to create Salary Database and link it to Employee.

1 Like