Managing Roles And Permissions In Custom Applications

I am building a SaaS application and I want to serve real customers. In this article, I am going to explain different ways to define user roles for a SaaS application and for each approach we will look at the merits and demerits.

Option 1 - Adding IsAdmin property at the user level

The simplest approach is to add a property IsAdmin at the Users node level, as shown below.

This is not a bad approach but when we add new roles in our application, managing this becomes a complex task.

Option 2 - Top-level Roles Node

Another approach is to have a top-level node, Roles, and under this node, we can add different roles, as shown below.

For example, we can have a role name and under this node, we can add all the users responsible for this role. In the future, if we want to add an additional role, we can simply add a new role.

If we are going to have multiple roles in our application, we can see that this approach scales better. It is cleaner and more maintainable but this approach does not scale well when we end up with complex conditional statements in our code.

Option 3 - Operation based roles

In this approach, we are going to manage the permissions based on user operations not with roles, as shown below.

This approach gives us the flexibility to control who can do what and enable or disable product features based on the pricing model. Also, this can be used to control trial software features.

Best Approach

There is no such thing as best in SaaS product development but personally, I like option 3 as I need to define roles in the core and customer database based on user operations. These custom roles come with some maintenance overhead. When we add new permissions, we need to think through whether they should be enabled for each custom role. A careful backfill is required to ensure that these roles get the appropriate permissions.