# \[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:** 1\ **Showing post:** 74
**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. --- _[View the full topic](https://community.fibery.io/t/done-entity-level-permissions/2163)._