[IN DEV] Entity-level permissions


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:

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.

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.


: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:

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

: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:

  1. :gem: “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…”
  2. :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.

I’m certainly missing a possibility to limit user access to a particular entity.

Some examples:

  • a user can see releases, features, stories and bugs only from those projects, assigned to the user’s team
  • I’d like to have multi-organization setup and have no concerns, that users will see goals or product plans not owned by his organization
  • while keeping task app for everyone, I’d like to create a subset exclusively for myself
  • I’d like to be able to limit visibility of certain entities to certain subsets of users
  • I’d like to create private boards for experimenting

Thanks a lot!


Yes to this. As of 24 Aug 2019 the permissions are app level only. That means, I can assign users to either see or not see an app. What I need is, for instance, if I make a folder in the wiki, I want to make that read only for most of the team, except for a couple people. I would use this for documents that should not be edited by just anyone, that the company is legally required to maintain and make available, like “rules of employment”.


@mdubakov, Interested in how close the implementation of this feature is planned in the roadmap? It is very important feature for our team. It is second priority after UI feedback speed for our needs.

By the way, where can I see the current roadmap?
Maybe you should consider writing a roadmap on a published Fibery board?

1 Like

We don’t have a roadmap right now, since public release will definitely affect it and change all the plans. Most likely it will appear near Jan. It means Entity-level permissions schedule is unclear at this moment.

1 Like

+1 here. Would need entity level permissions to map sensitive processes like 1:1s, performance and salary reviews.


Updates on this?? It’s a big reason my team is skeptical.


Hey Guys, I don’t mean to pile on but since we have some activity here from @julian, I would like to add my vote. I would be happy with Type-level permissions if that was easier. Ultimately, Entity-level is superior.

Just for some context, I really like apps like Wrike, Asana, ClickUp, and some others that will add you as a share/viewer when you comment @ a particular user.

I would also love to see this feature come along at a similar time:

Thanks guys and keep up the great work!


+1 on this.

My use case is as a product lead for many products (aka sites) of our web agency. I’d like to create “spaces” for each product utilizing the same setup of entities. Whenever I try to create entity relations it should only show entities within the “space”. I tried to implement a setup like this and almost made but it failed on the fact that I can’t filter available entities during lookup when creating a relationship.


I just thought I would add in my use case for entity permissions and that is a role-based implementation, i.e. a user has one or more roles, and it is the roles that determine the access levels on an entity (or at least app-level) basis. I don’t need to figure out which apps a user should have access to, I just assign them to the necessary roles.
It’s obviously very analogous to traditional file permissions based on user groups.
[I think I’ve mentioned it to the fibery team directly, but I’m adding it here to open up the discussion]

@mikael Your need seems to maybe relate to filtering and views combined. Were you aware that you can use filters in formula fields to return linked entities based on the filter criteria? I think combining suitable lookups/filters with the various views available in fibery, you might be able to achieve what you have in mind (assuming I’ve correctly understood where you’re coming from).
It’s not clear to me whether permissions is really what you need…


We are working on permissions and will not stop till entity-level permissions are implemented. However, it might take 4-6 months to get there.


Great to know the time horizon. Rome wasn’t built in a day! :slight_smile:


Michael, it was good to hear from you re: permissions, would be curious if you could shed any light on whether you guys will also be looking at Type-level:

Many of the tools I’ve used have nice ways to handle these levels of permissions. One of my favorite, which is central in Wrike, and Asana, and ClickUp - who I might loosely consider a similar “triumvirate” of “Task Managers” like Airtable/Coda/Notion is within the “nocode” sub-space, all do this:

  • If you @mention a user within a comment stream, they get added just to that particular task

  • You can “share” lists/folders/projects to a particular group.

So in the case of Fibery, I think you have a great chance with your existing hierarchy to do a similar approach that would be very familiar to those coming in from these tools - and perhaps others who handle things similarly like Hive, Monday, Teamwork Projects, etc.

So in Fibery this would work out as:

  • You can access particular users to a Type, much as you do now with a whole App

  • via mentioning a user, they get access to an individual Entity only.

The addition of the Type-level permission makes it easier to break down groups of Entities within an App. I have this need in Task Management I am running in Fibery, where I have groups of Tasks in Types that I’d like to have only certain users see, and not the whole App’s worth of Types.

Hope that’s useful and curious to see how you guys will solve this!

1 Like

Any updates on this topic. We are still longing for a solution on the use case of inviting a user to a specific entity and the user will then have access and be able to collaborate on all related children entites in an parent-child relationship.

Entity-level permissions the #1 customer request for us so we are committed to delivering a solution. The problem is quite challenging, both in terms of UX and technical solution — we are still in the preliminary design phase.

Once we have something “feedbackable”, I’ll be happy to share it with the community. In the best-case scenario, the beta will start the upcoming winter.


Hey! Just wanna know if there is any advancement on this? I have a client who is waiting for that. :slight_smile:

Unfortunately implementation is not started yet, but we hope to start it in April.

1 Like

What is the ETA on this? This is the only functionality stopping us from moving to Fibery from coda / notion / clickup / airtable.

Still not started. Still want to start it in 1-2 weeks.

1 Like

Permission rules as they are realized at GRIST are the most expected realization for me