Managing Roles And Permissions In Custom Applications

In this article, we will learn different ways of defining user roles for a SaaS application along with the merits and demerits of each way.

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.

Managing Roles And Permissions In Custom Applications 
 
This approach is easy to control but does not scale well when we want to provision things based on different roles. For example, in the future, if we are going to have another role like HR Admin, we will have to add another property here like this.

 

Managing Roles And Permissions In Custom Applications

 

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.

 

Managing Roles And Permissions In Custom Applications

 

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.

Managing Roles And Permissions In Custom Applications

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. 

A special thanks to Mosh who explained these scenarios in Firebase --  that helped me a lot. Hopefully, this helps the viewers. In future posts, we will go a bit deeper about SaaS Application Architecture. As a SharePoint Evangelist, my professional interests tend to be technical and SharePoint focused. I hope the posts in my blog will give back a little to the community that has helped me.