Introducing Entity-level permissions will unlock new opportunities:
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.
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®).
Delegating tasks to contractors, splitting CRM among sales folks — the list goes on…
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.
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.
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.
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
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).
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.