One pattern with some types of SaaS apps is that you have three groups of users. The first is the “tenant” users, the people who actually pay for the SaaS. They use it for something that attracts the second group, their customers. The third group is you and the people working on the SaaS who need to administrate the app itself.

Some examples:

  • Property - Estate Agents, Enquirers, Portal Admin users
  • E-Learning - Trainers, Learners, Platform Admin users
  • Self Storage Management - Site owners, Storage Rental customers, Platform Admin Users

If you pick a SaaS app at random you might find all these user types in a single table called ‘users’. That table will have a flag or role field that says which type of user they are. The User model is a “god” object with associations to nearly everything else in the system even though some of these associations only apply to a particular user type. This pattern scares me because one mistake and a regular user could get “promoted” and have access to data they shouldn’t be able to.

In any app I’ve started in the past few years that has this pattern I’ve split each user type out into its own table. Each type gets their own set of auth pages, configured appropriately. You can make Admin users have to be on a VPNs, Tenant users can choose to have 2FA, and Customer users can have social logins enabled. This is all done without any extra complexity in the models themselves. It requires a bit more work at the start and can mean some extra join tables but in general I’ve been much happier with trading this off for a better separation of concerns.

If your app is like this how have you handled these different user types?