RBAC Application Examples in Real World B2B Products

Role based access control (RBAC) is a method of deciding who gets access to what based on their role. If you’ve ever used a product where some users are "Admins" or "Moderators", and they have more authority than a regular user, you’ve used a product with RBAC.

In this post, we’ll look at some real world applications using RBAC to see the value of designating hierarchal roles. You might be surprised by how some very large applications have thrived for a long time with very simple role structures.

The simplest possible role setup

Pipedream is a low code integration startup that launched in 2019 and utilizes a two-option RBAC. When you sign up, you can create an organization, which will allow you to invite your coworkers. Pipedream then enables you to set your role structure within your organization where each user is either an 'Admin' or 'Member'.

This differentiation is actually really great and highlights an important point:

Complexity within your roles is complexity that your users need to deal with.

With this quick and painless setup, it’s pretty obvious who has extra permissions and who doesn’t. In fact, we can look at another larger company, Notion, to see another example of this simple role setup:

Notion added a longer description and a slightly nicer interface but, under the hood, it’s the same. Users are either 'Admins' or 'Members'.

If you are building a new product, it’s worth asking yourself, "What’s the simplest role structure I can get away with?" You can always add additional roles over time, but it can become tricky to remove existing roles as you may inadvertently change people’s access and permissions.

Adding additional roles

Owners

There are some limitations with only two roles, for example:

• I don’t want every ‘Admin’ to be able to delete the organization
• I don’t want every ‘Admin’ to handle billing information

Typically, this can handled by creating a higher leveled-role, often called an ‘Owner’.

This three-level role structure (Owner, Admin, Member) is pretty common, and a feature that PropelAuth provides by default.

Guests

Similarly, you can also add an additional role underneath ‘Member’, which we will call ‘Guest’. When a role is added underneath ‘Member’, it’s usually for a user that has heavily limited permissions.

Within these roles, you can also configure your role permissions to your specific needs. Slack, for example, has four roles including ‘Owner’, ‘Admin’, ‘Member’, and ‘Guest’.

In this case, ‘Guests’ are users that don’t have access to every channel, but, instead, are limited to specific channels and/or have specific permissions. This limited type of role could be helpful for contractors or interns, who don’t need full access to the company’s data to perform their jobs.

Examples where users define their own roles

We’ve covered most of our bases. You can start with ‘Admin’ and ‘Member’, and if you need more granularity, you can add an addition roles above ‘Admin’ or beneath ‘Member’. What’s left?

You can create dedicated roles to specific actions like a ‘Billing Manager’ role and a ‘Security Manager’ role - which is what Github does. These roles will be equal in hierarchy but have a different set of permissions related to their functions.

One example of a company that allows for a lot of extensibility, is Datadog.

As a baseline, Datadog starts off with three roles (‘Admin’, ‘Member’, and ‘Read Only’). The difference is Datadog allows you to create your own custom roles and assign permissions to them, such as a ‘XYZ Manager’ who is able to XYZ task/access.

Last, but certainly not least, we have AWS. Similar to Datadog, you can create your own custom roles each with their own permissions. However, AWS doesn’t start you off with just three roles, but with many, many more.

If you’re at an early stage, this choice overload can be overwhelming, and likely isn’t helpful to the majority of businesses even as they expand. You only really see cases like this if you need incredibly granular permission-ing.

So what role setup should I use?

The number and types of roles will depend on your company stage and your product requirements, however, we recommend keeping it as simple as possible. As shown, many successful startups and large public companies only need 2-4 roles total, while others may need more.

To reiterate our point from earlier, complexity within your roles is complexity that your users need to deal with. You will potentially need more complexity over time as your customers grow and have more unique needs, but while you are small, you can save a lot of time and stick with a very simple approach. And hopefully, you can avoid needing a setup as complicated as AWS.