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 
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 
) 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.
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?
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 
.
Hopefully, these sensible defaults will work for most scenarios:
Here is how they look in a real fictional Workpsace:
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:
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
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:
“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…”- “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.
