The plans for the new permissions model do not include field-level permissions (or block-level).
The granularity is to the level of entity.
If this is not acceptable for your current schema, then you’d need to split databases to create the granularity you need
entity level is a great start 
no - i think i will be very fine with that … was just an idea while thinking of a dream setup … but i do get that this would be a bit much …
right now, when adding entities of unshared spaces to entities/documents that are shared, they are visible or invisible to another user?
like “contact” (unshared) linked to (relationship field) or added inside a doc with # in a “meeting”(shared). does the contact.name show up or not?
If a user can’t see something in the space it comes from, they can’t see it if it is mentioned in entities/docs in other spaces.
You can always experiment with this by creating a dummy account with different permissions, and check out how the workspace looks to them.
Very very excited for this! If/when you’re in need of beta testers, hit me up!
Party time!!! 
That is SO great!! Well done 
*Studies screenshots in detail… * 
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…
… 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:
It seems like there are lots of questions, and tbh, I don’t think we will answer them all 
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 
Will wait and see! 
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!
That was not planned. Any use case you have in mind?
actually, that is one of the main things i hope you implement
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! 
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 
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.
