# \[DONE\] Entity-level permissions **URL:** \ **Category:** Ideas & Features\ **Tags:** permissions, sharing\ **Created:** [October 29, 2021, 2:32pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163 "2021-10-29T14:32:55Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 28, 2023, 3:00pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/61 "2023-09-28T15:00:33Z")
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 👍 ---
**Author:** ![bear](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/bear/32/12872_2.png) [@bear](https://community.fibery.io/u/bear)\ **Post date:** [September 28, 2023, 6:06pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/62 "2023-09-28T18:06:10Z")
Awesome! 💪 It’s looking great! 😍 Thanks for the update! ---
**Author:** ![YvetteLans](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yvettelans/32/6101_2.png) [@YvetteLans](https://community.fibery.io/u/YvetteLans)\ **Post date:** [September 29, 2023, 11:56am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/63 "2023-09-29T11:56:51Z")
> [@mdubakov](#): > > It is taking shape Awesome! 😍 > [@Matt\_Blais](#): > > 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 👍 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 🥳🥳 ---
**Author:** ![cannibalflea](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/cannibalflea/32/318_2.png) [@cannibalflea](https://community.fibery.io/u/cannibalflea)\ **Post date:** [September 30, 2023, 12:41am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/64 "2023-09-30T00:41:24Z")
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](https://community.fibery.io/t/setting-field-ui-properties-based-on-conditions/5226) 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. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [October 2, 2023, 3:38pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/65 "2023-10-02T15:38:50Z")
> [@cannibalflea](#): > > I am hoping we are able to get to be able to have some field level controls 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. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 2, 2023, 3:46pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/66 "2023-10-02T15:46:27Z")
I see a different possibility, though perhaps you don’t intend to implement that either: > [@Individual Layouts for a node, hide fields etc](https://community.fibery.io/t/individual-layouts-for-a-node-hide-fields-etc/995): > > This may be some work … Currently the displayed layout of a Model shows all items. One good thing is, you can sort the fields. But you can not hide any. Seeing “creation date” and other fields for example is most times useless and overloads the page. BUT it is not a good idea to make it globaly for all views of a model anytime. It should be a way to have different layouts. Not sure what could be a good logic. Maybe it may depending on where you opened it? In any case a toggle for “show all f… If you had multiple layouts for a given database (entity view), _and_ they could have unique security settings per-layout (which I would think is easier to implement than per-field permissions), then you could simply put sensitive fields (ones that not everyone should see) onto a different layout with special permissions. The likely failure case for at least some people would be desire to have fields that are _visible_ but not editable, depending on permissions, which becomes more field-level permissions than unique layouts. 🤔 ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [October 2, 2023, 3:52pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/67 "2023-10-02T15:52:46Z")
> [@Oshyan](#): > > If you had multiple layouts for a given database (entity view), _and_ they could have unique security settings per-layout (which I would think is easier to implement than per-field permissions), then you could simply put sensitive fields (ones that not everyone should see) onto a different layout with special permissions. The problem with these sorts of workarounds is that if the permission control is not strict (and relies solely on UI) there are ways that sensitive data can ‘leak’. For example, API access is not affected by view settings. Or if a user has creator access in one space and read-only access to the space containing the ‘sensitive’ field, he/she can create views/formulas that do not have the same limitations (hidden fields) as those created by other people. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 2, 2023, 3:58pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/68 "2023-10-02T15:58:38Z")
That’s a fair and important point. My resulting question would be: assuming there is enough utility in the “individual layouts” feature request, and that implementing permissions per-layout is not hard, would it not be better to have _some_ solution than none? I get that a solution that offers a false sense of data confidentiality is not good, so there would have to be some caveats around that, but I do think people would still get plenty of value out of it. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [October 2, 2023, 4:15pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/69 "2023-10-02T16:15:25Z")
Possibly. But I suspect we would be more likely to be head down a route where adding a (strictly controlled) linked database is as easy as adding a new field (and where it is possible/easy to edit the linked entity’s properties without having to navigate to it - all subject to permissions of course). ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 2, 2023, 7:59pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/70 "2023-10-02T19:59:37Z")
Ah, fair enough then! I still want multiple layouts per DB/entity type, but what you describe also sounds very useful. ---
**Author:** ![cannibalflea](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/cannibalflea/32/318_2.png) [@cannibalflea](https://community.fibery.io/u/cannibalflea)\ **Post date:** [October 2, 2023, 8:07pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/71 "2023-10-02T20:07:28Z")
@Chr1sG I understand the limitations. As @Oshyan pointed out, I guess the options we are suggesting (either having [conditional control over fields](https://community.fibery.io/t/setting-field-ui-properties-based-on-conditions/5226) and/or [multiple layouts](https://community.fibery.io/t/individual-layouts-for-a-node-hide-fields-etc/995)) would be half measures from a permission-perspective but they would also have other useful benefits. So they can be suggested as possible workarounds (along with separate dedicated database as @mdubakov indicated) each with their own limitations, so creators can choose based on their needs. For example, in many cases, hiding or locking fields is not so much a matter of security but convenience/user experience. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [October 3, 2023, 6:12am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/72 "2023-10-03T06:12:41Z")
> [@cannibalflea](#): > > For example, in many cases, hiding or locking fields is not so much a matter of security but convenience/user experience. This is true, but it is orthogonal to permissions. Entity Views is something we do want to dig into eventually. ---
**Author:** ![YvetteLans](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yvettelans/32/6101_2.png) [@YvetteLans](https://community.fibery.io/u/YvetteLans)\ **Post date:** [October 3, 2023, 11:40am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/73 "2023-10-03T11:40:49Z")
> [@Chr1sG](#): > > Possibly. But I suspect we would be more likely to be head down a route where adding a (strictly controlled) linked database is as easy as adding a new field (and where it is possible/easy to edit the linked entity’s properties without having to navigate to it - all subject to permissions of course). This sounds very helpful for GPDR use cases! ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [October 3, 2023, 4:03pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/74 "2023-10-03T16:03:26Z")
> [@Chr1sG](#): > > adding a (strictly controlled) linked database is as easy as adding a new field (and where it is possible/easy to edit the linked entity’s properties without having to navigate to it **If that’s like a JOIN, that would be FABULOUS 🤩** – i.e., if we could treat/use a linked entity’s fields as we can the main entity – and it would answer a big part of the need for some kind of polymorphism, and allow for much better DB normalization. > [@"Joins" - include related entity's fields in Views](https://community.fibery.io/t/joins-include-related-entitys-fields-in-views/1966/3): > > Yes, this is related to Inheritance-like functionality: Example: If I have a Project Type that is related (1:1) to a SEO Info Type, my desire is for a Projects Table View that can display and edit the fields of the related SEO Info entity (if it exists). The issues with using Lookups for this are: Each Lookup field must be manually created (cumbersome, and error-prone if field definitions change) Lookups do not allow editing the related values in the Table View > [@Allow Automations to Update entities via Lookup fields](https://community.fibery.io/t/allow-automations-to-update-entities-via-lookup-fields/3006): > > I am frustrated by the inability of Rules to Update entities related through a Lookup unamused It means more Javascript, which seems unnecessary. > [@Allow Rules to trigger "When linked entity is Updated"](https://community.fibery.io/t/allow-rules-to-trigger-when-linked-entity-is-updated/2927/3): > > @Chr1sG, yes there are existing workarounds. The case for this is really about reducing complexity, i.e. not having to create additional lookups, and avoiding having to remember that a particular field is actually modified from a related entity (which is not how I like to build things). It’s a maintenance headache. I have actually found myself forgetting why I created a particular lookup or relation, and deleting it, only to (re)discover later that it was added it to perform some kind of work-… > [@How to best model Hierarchical Types?](https://community.fibery.io/t/how-to-best-model-hierarchical-types/1907/4): > > The goal is to make the schema/DB structure as clean as possible; i.e., no duplication of fields, and no extraneous fields. (see [Database Normalization](https://en.wikipedia.org/wiki/Database_normalization)) So e.g.: all of the different project types need “tasks”, so “tasks” should belong to a generic “parent” Project type. only “website projects” need a URL (brochure projects do not), so the URL field belongs in the “website project” type, not in the generic Project type. ---
**Author:** ![Robert\_B](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/robert_b/32/7198_2.png) [@Robert\_B](https://community.fibery.io/u/Robert_B)\ **Post date:** [October 3, 2023, 8:55pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/75 "2023-10-03T20:55:54Z")
This looks amazing. ---
**Author:** ![Nevil\_Hulspas](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/nevil_hulspas/32/4703_2.png) [@Nevil\_Hulspas](https://community.fibery.io/u/Nevil_Hulspas)\ **Post date:** [October 14, 2023, 5:48am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/76 "2023-10-14T05:48:26Z")
This is great, really looking forward to using it! I assume entity level permissions will be inherited from the database level by default? Something like Notion has by using “based on”: ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/6/6ebb67a87849f84ab97767fcd1ccce0e8c0fb5a0.jpeg) Also, I’m not fully sure what is meant by the extend button. What does it do? Can’t figure it out from the video. It looks like it just shows which other databases that specific user has access to, but not sure what the added value is in showing that there. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [October 14, 2023, 7:13am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/77 "2023-10-14T07:13:29Z")
> [@Nevil\_Hulspas](#): > > I assume entity level permissions will be inherited from the database level by default? Can you clarify this a bit? > [@Nevil\_Hulspas](#): > > Also, I’m not fully sure what is meant by the extend button. What does it do? Can’t figure it out from the video. For example, you have Product and inside you have Features and Tasks. When you just share Product A with some person, all related Features and Tasks are not shared (so far). When you click Extend button, only then all features and tasks are shared ---
**Author:** ![Nevil\_Hulspas](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/nevil_hulspas/32/4703_2.png) [@Nevil\_Hulspas](https://community.fibery.io/u/Nevil_Hulspas)\ **Post date:** [October 15, 2023, 5:02pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/78 "2023-10-15T17:02:20Z")
> [@mdubakov](#): > > For example, you have Product and inside you have Features and Tasks. When you just share Product A with some person, all related Features and Tasks are not shared (so far). When you click Extend button, only then all features and tasks are shared Ah so it’s only regarding relations? Seems like a good one. > [@mdubakov](#): > > Can you clarify this a bit? Sorry I meant “space” instead of “database”. ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/3/3774e00c225bca497547e72b0550f7f6f39018a4.png) So since sharing is determined on the space level, will that propagate to it’s child databases / entities automatically? I would assume yes, just wanted to know if that’s the case. ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [October 17, 2023, 7:48am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/79 "2023-10-17T07:48:18Z")
> [@Nevil\_Hulspas](#): > > So since sharing is determined on the space level, will that propagate to it’s child databases / entities automatically? I would assume yes, just wanted to know if that’s the case. When you share a Space, you share all databases and all entities in this space. It works this way now. ---
**Author:** ![Ryan\_Dejaegher](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ryan_dejaegher/32/8050_2.png) [@Ryan\_Dejaegher](https://community.fibery.io/u/Ryan_Dejaegher)\ **Post date:** [November 1, 2023, 12:37am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/80 "2023-11-01T00:37:48Z")
This looks awesome! I don’t think it was mentioned in the video but would this be able to support something like adding view permissions to a third party client (I’m thinking agency-client context). In some cases I may not need a client to become a full blown member of the Fibery space, but would still like to give them access to a client specific board or document where they can see progress of tasks on a board and also comment. [Previous page](https://community.fibery.io/t/done-entity-level-permissions/2163.md?page=3) [Next page](https://community.fibery.io/t/done-entity-level-permissions/2163.md?page=5)