# \[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:** 15\ **Page:** 6
**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:** [November 30, 2023, 8:50am UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/101 "2023-11-30T08:50:19Z")
> [@Yuri\_BC](#): > > That is amazing, looking forward to that! The extend capability already exists in the (experimental) entity permissions, but for the default access levels, it only applies to one level down. > [@Yuri\_BC](#): > > can it extend unlimited in a hierarchical relationship tree? When we roll out custom access templates, they will allow propagation to multiple (but not unlimited) levels. ---
**Author:** ![Jonathan\_Oaklyn](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jonathan_oaklyn/32/8392_2.png) [@Jonathan\_Oaklyn](https://community.fibery.io/u/Jonathan_Oaklyn)\ **Post date:** [December 14, 2023, 6:43pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/102 "2023-12-14T18:43:50Z")
We often need to share individual entities in Fibery with our clients. We are a custom dev shop and want to, for example, create a checklist for our clients to be able to complete themselves without having to add full user seats for every person working for the client. Being able to either add guests that can edit only certain documents, or create public links that allow editing would be super helpful. ---
**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\ **Post date:** [December 18, 2023, 9:26pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/103 "2023-12-18T21:26:20Z")
> [@Chr1sG](#): > > When we roll out custom access templates, they will allow propagation to multiple (but not unlimited) levels. I think that people are generally accustomed to the idea of folders and that everything in a restricted team folder is therefore also restricted to team members only. This applies to any content type in the folder, including subfolders. With the ‘not unlimited access propagation’ in hierarchical relations, this becomes less clear why there is a limitation, since there is not structural logic for that, other than the potential performance logic of the developers. If the levels of propagation is limited, then I think users need to be warned that if they create child relations beyond that, it will not inherit the access restrictions. How would they be warned? How do the fibery designers solve the common expectation about access propagation, when users create nested strudtures like: Company \> Department \> Group \> Team \> Project \> Milestone \> Task \> Dependent Task \> Action \> Note etc… ? ---
**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:** [December 18, 2023, 10:43pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/104 "2023-12-18T22:43:35Z")
> [@Yuri\_BC](#): > > If the levels of propagation is limited, then I think users need to be warned that if they create child relations beyond that, it will not inherit the access restrictions. How would they be warned? Access is managed through overloading of granted (positive) permissions, not through restrictions. So if levels are added beyond the limitations of an access template, these levels will be inaccessible by default. > [@Yuri\_BC](#): > > this becomes less clear why there is a limitation, since there is not structural logic for that, other than the potential performance logic of the developers. Fibery structure is not limited to simple one-to-many pyramid hierarchies, so although access might be simple to apply in that specific case, the permissions model needs to accommodate all the possible (crazy) structures that users might come up with, and not break or get too slow. > [@Yuri\_BC](#): > > How do the fibery designers solve the common expectation about access propagation, when users create nested strudtures like: > Company \> Department \> Group \> Team \> Project \> Milestone \> Task \> Dependent Task \> Action \> Note etc… In that example, I would imagine that users would have access to the project(s) they are working on and with propagation, to all the ‘downstream’ items (milestones, tasks, actions and notes). Access to departments, groups and teams would be governed by their membership of a team, and through lookups, their implied membership of a group and a department (not via access template propagation) This would probably be something similar to the current ‘contributor’ level. We haven’t so far heard of a lot of use cases that aren’t covered by access propagation which is limited in the number of possible levels. ---
**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\ **Post date:** [December 23, 2023, 7:43pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/105 "2023-12-23T19:43:52Z")
Related: > [@Exploring solutions for a controlled relationship structure](https://community.fibery.io/t/exploring-solutions-for-a-controlled-relationship-structure/5577/3): > > I don’t think field level permissions is actually the solution to this. A relationship is actually two fields (one at each end) so it begs the question which field governs the permissions. I think a more plausible solution is that the capabilities available in custom access templates get expanded so that the current ‘Edit’ capability (which encompasses the ability to link/unlink items) is split into a limited ‘Edit’ and a separate ‘Link/Unlink’ capability. No idea of if/when this will happen t… ---
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [January 10, 2024, 9:38pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/106 "2024-01-10T21:38:53Z")
Is there a plan to increase the level of granularity on permissions? Specifically for the “Update” permission, as in it’s current form it’s pretty wide ranging. My suggestions: - Create new entities in related databases - Link to existing entities in related databases - Unlink entities in related databases - Edit “basic” fields - Create & modify “basic” fields - Delete “basic” fields - Create & modify “advanced” fields - Delete “advanced” fields - Create & modify views - Delete views - Toggle visibility of fields - Click buttons ---
**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:** [January 10, 2024, 11:25pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/107 "2024-01-10T23:25:10Z")
> [@interr0bangr](#): > > Create new entities in related databases This is a permission for the related db, not the entity itself. > [@interr0bangr](#): > > Create & modify “basic” fields > Delete “basic” fields > Create & modify “advanced” fields > Delete “advanced” fields > Toggle visibility of fields These are all part of ‘Creator’ access for the database, and I don’t think we will offer more granularity than that any time soon. > [@interr0bangr](#): > > Edit “basic” fields Not sure if you mean edit=configure fields or if you mean edit=update field values. If the former, then this too will remain under Creator level for the db. If you mean that you want to split the current ‘entity update’ permission into the following: > [@interr0bangr](#): > > Link to existing entities in related databases > Unlink entities in related databases > Edit (=update) “basic” fields > Click buttons then there may be a small chance a greater level of granularity may arrive somewhere down the line, but please tell us your use cases, so we know what’s in your mind. > [@interr0bangr](#): > > Create & modify views > Delete views Permissions for space views are independent of databases/entities (except in as far as you can’t expect to be able to create a data view for dbs/entities that you don’t have view access for!) The view-specific settings (columns, filters, sort etc.) are in the hands of space ‘creators’. Relation views are a whole other story, but let’s not go there 😉 ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [January 11, 2024, 4:38pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/108 "2024-01-11T16:38:24Z")
> [@interr0bangr](#): > > Is there a plan to increase the level of granularity on permissions? Based on recurring use cases, we might split a capability into two or three, but not more. We are balancing flexibility and complexity here. Actually, we started with a more granular set but collapsed it after noticing how intimidating it looked. ---
**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:** [January 13, 2024, 2:26pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/109 "2024-01-13T14:26:23Z")
@antoniokov is there a real-rough-not-to-pin-you-guys-on-it estimation when the following use case is possible: **a user has only access when assigned to the entity or when he/she created the entity** We currently need to decide if we create a more or less ‘separate team space’ for our customers where their team members can only see their own tasks, projects, appointments, notes etc. (still not waterproof since they can use search/link as well, but it’s at least something). If this feature is quite nearby, we will not do that since it’s a lot of work that’s not needed after this is implemented. ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [January 15, 2024, 4:58pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/110 "2024-01-15T16:58:45Z")
> [@YvetteLans](#): > > a user has only access when assigned to the entity or when he/she created the entity Likely to happen by the end of Q1, veeery likely to happen by the end of Q2. I’ll have a better estimate as soon as we start the development. ---
**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:** [January 15, 2024, 6:38pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/111 "2024-01-15T18:38:40Z")
Thanks for the update! We’ll keep our fingers crossed 🤞🏻😁 ---
**Author:** ![Illusory](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/illusory/32/10403_2.png) [@Illusory](https://community.fibery.io/u/Illusory)\ **Post date:** [June 29, 2024, 1:09pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/112 "2024-06-29T13:09:01Z")
> [@YvetteLans](#): > > **a user has only access when assigned to the entity or when he/she created the entity** We certainly need this as well! Hoping this is coming soon. ---
**Author:** ![Lee\_Denny](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lee_denny/32/8158_2.png) [@Lee\_Denny](https://community.fibery.io/u/Lee_Denny)\ **Post date:** [October 18, 2024, 12:38pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/113 "2024-10-18T12:38:57Z")
Is this still planned? ---
**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 18, 2024, 12:43pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/114 "2024-10-18T12:43:16Z")
It is implemented in fact [https://the.fibery.io/@public/User\_Guide/Guide/Share-Entity-233](https://the.fibery.io/@public/User_Guide/Guide/Share-Entity-233) ---
**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 18, 2024, 2:02pm UTC](https://community.fibery.io/t/done-entity-level-permissions/2163/115 "2024-10-18T14:02:58Z")
[Previous page](https://community.fibery.io/t/done-entity-level-permissions/2163.md?page=5)