Why? So far all the access management in Fibery happens on the App level. The only way to share an individual Entity (ex. a Task) with a teammate is via read-only external sharing :poop: [image] Introducing Entity-level permissions will unlock new opportunities: Collaborating with clients As we’ve learned, Fibery is a surprisingly good fit for many service companies: think digital agencies and development studios. A good fit, that is to say, before we start talking about access management. Creating an App (or a Workspace :grimacing:) per client is a workaround for the most desperate. Most just say “screw it” and we can’t blame them. Being able to share a Project with the client would be a game-changer. Aligning departments around a product/objective/etc. Some huge endeavors require all departments to chip in. This means the relevant knowledge is scattered across different Apps. [image] Sharing everything inside a Product, Objective, or Initiative would facilitate cross-functional collaboration™ (buy our book on successful enterprise success®). Solving climate change Delegating tasks to contractors, splitting CRM among sales folks — the list goes on… Also, based on how Fibery works under the hood, we need some form of Entity-level permissions to build My Space, Read-only users, and collaborative external sharing. How? :face_with_raised_eyebrow: You might ask: if they are so important, why the fu Entity-level permissions haven’t been implemented yet? Well, they are extremely hard to get right — even conceptually, without thinking about UI and implementation. Hopefully, we think we have a decent model. Here it is. Sharing a single Entity There are 4 default levels of access (the same is in Notion, what a coincidence): Can View Can Comment Can Edit Full Access Those with Full Access are free to share an Entity with an individual User or a Group by picking one of these levels. All Entity “companions” are shared automatically with the same level: Files, Documents, Whiteboards, etc. Sharing Entity and its children To share a Project and all its Tasks (and their Subtasks), we need some kind of inheritance. Fibery knows better than vertical hierarchy distinguishing between one/many — one/many relations and making things difficult for permissions :woozy_face:. Hopefully, these sensible defaults will work for most scenarios: [image] Here is how they look in a real fictional Workpsace: [image] A person with Full Access to a particular Objective will have the same access to its Key Results, Ideas, Features, and Stories. Defining custom access templates Default access levels and inheritance rules work for most but not all scenarios. That’s why Creators are free to define their own custom access templates for a particular Type. For example, here’s Client access template for Customer Type: [image] It allows to automatically give a client’s manager access to all the Projects and Stories but not to Contacts (hiding cheeky notes) or Tasks (avoiding micromanagement). What’s next :sparkles: For the most curious readers, here is the entire new access model in its spectacular boring glory: Permissions United. We would love to hear your feedback! Specifically, two kinds of it: :gem_stone: “Looks great! You haven’t even mentioned this scenario but it’s gonna work: to share my dog’s resume, I’d create a new access template…” :poop: “Complicated and doesn’t solve my case: we have 1408 clients communicating with us through a psychic…” Please share your cases here or, if you prefer some privacy, via Intercom.

It is implemented in fact https://the.fibery.io/@public/User_Guide/Guide/Share-Entity-233

Welcome @Lee_Denny to the Fibery Community! :smile:

For the common scenario of users needing access rights to organic groups and organic group content , where the term group is not the permission groups in the admin section, but groups that can be created by users without admin intervention: If we have the same database ‘Task’ that is used across 100 organic groups, If organic group membership means that an organic group manager can approve individual membership requests I assume that: There is a way to set permissions for each organic group enitity such that the tasks related to that entity can not be accessed when a user is not member of that group. ?

Also, if permissions can be depedent on an entity level relationship, then a feature/setting ‘required relationship’ is needed in the database field setting, to make sure that people do not forget to assign it to a group/project if that enables the permissions.

Based on my understanding of what you are describing, this is possible with the new permissions model, using the ‘extend’ capability. That is to say, if a Team is linked to Tasks (one-to-many) it is possible to configure the permissions so that access to the Team automatically implies access to its Tasks. Eventually, it will be possible to automatically grant Project access based on a User relation to the Project (i.e. any User linked via the Member field has the permissions needed).

[image] Chr1sG: the ‘extend’ capability That is amazing, looking forward to that! Would the ‘extend’ capability apply to the first level relationship, or can it extend unlimited in a hierarchical relationship tree? I’m thinking of for example top-down lockdown of: Company > Department > Group > Team > Project > Milestone > Task > Dependent Task > Action > Note etc…

[image] 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. [image] 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.

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.

[image] 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… ?

[image] 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. [image] 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. [image] 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.

Related: [image] Exploring solutions for a controlled relationship structure Get Help 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…

[DONE] Entity-level permissions

Ideas & Features

Yuri_BC December 23, 2023, 7:43pm 105

Topic		Replies	Views
Permissions - entities vs views Ideas & Features permissions	36	2161	December 7, 2022
Nov 16, 2023 / 🔒 Entity permissions (experimental) Changelog	59	2551	June 18, 2024
Feature Request: Share Space but restrict entity views Ideas & Features permissions	53	943	March 29, 2025
Q3 2025 Roadmap News & Announcements	76	1917	September 15, 2025
May 21, 2026 / 🫣 Manage users visibility, Send web request action in automations Changelog	24	670	October 7, 2026

[DONE] Entity-level permissions

Related topics