Group Permissions That Blend Into Collaboration Software

Lately, larger and larger companies started to adopt Fibery, so managing access in batches has become a pressing issue. A nice problem to have, indeed.

Naturally, our first idea was to implement permission groups for the 1024th time in the history of software. Then we remembered that Fibery has an unfair advantage over most of the SaaS software — its flexible data model. So instead of introducing standalone “permission groups” we hijacked an existing functionality — just like we did with integrations.

Traditional approach

Access management is not the sexiest feature in any collaborative tool. Product managers and designers don’t fight for the right to design it — but somebody has to do it. So this poor person simply adds a new screen in the outskirts of the product, not worrying how it fits in the grand schema of things.

To be fair, it’s usually not much integration that can be done between permissions and the rest of the app in traditional tools.

However, even in modern no-code tools like Notion users and groups are not first-class-citizen databases — but rather a standalone functionality.

We took a different approach and here is why.

Modeling an organization

Every comprehensive work management tool serves as a model of an organization. Most of the collaboration software focus on modeling work hierarchies: tasks sliced by projects or features organized in epics. Unlike others, Fibery also cares about people (ha-ha, no full stop here) organization: employees grouped by teams and roles.

Having users, teams, and roles as first-class citizens in our data model, unlocks a powerful scenario:

Or two:

Or three:

To be honest, there are plenty of scenarios — most invented by our customers, not ourselves. Now we are adding another one — managing access.

Hijacking existing groups

Tribes, teams, squads, roles, and all other kinds of people groups are already represented in Fibery workspaces. So instead of adding standalone “permission groups”, we give existing groups the power to manage access.

Any Type (~database in Fibery) having a collection of users can be used as a permission group:

Each user can be a part of multiple teams and serve multiple roles in the company:

Each Fibery App (~company area) like Product Management or CRM is shared either with specific people or entire groups (or both):

Note that you are free to mix teams and roles, tribes and squads here. This will come extra-handy once we have granular access to specific projects and tasks, not just entire Apps.

If you own a Fibery workspace with 20+ people, configure the groups and let us know how it goes.

More power to the groups

While traditional permission groups continue to be single-purpose, we expect Fibery Groups to gain even more power:

• Reuse Okta/ActiveDirectory groups as Fibery groups and worry about the other 98 problems.
• Mention groups, not just individuals, in the comments and collaborate easier.
• Follow certain projects as a group and get notified promptly.

These are the things that our mediocre team has come up with. Our amazing customers will certainly come up with crazier and more inventive group superpowers. Can’t wait!