New SaaS project: Super Admin & Client Admin, how to structure?
Hi! We are about to rewrite our admins and i would like som tips/recommendation regarding how to structure this.
Today, we have one admin for our clients, where they can change different settings such as billings etc. Then we have an admin for our Super Admins / Account Managers. The "Super admins" can change global settings for the product itself, customer permissions etc. and are also able to change settings on behalf of a customer. So a super admin can change everything for a customer.
Today the super admin "login" as a customer through the global admin and then ends up in the client admin as the user.
I don't like it that way and would like som tips on how to structure this a better way (if there is one?). I prefer that the super admin doesn't leave the super admin when helping a customer out.
Do you have any recommendations?
12 Replies
Hey. I had a bit of a hard time to follow you, but as i understood, you have three Roles here. Customer, Admin and Super Admin.
I would recommend to put each role in their own in subfolder, thus /pages/customer (or just /pages), /pages/admin, /pages/superAdmin.
Use a middleware to redirect users to a Forbidden page in case they try to access a role's 'folder' (route) they do not have permission to.
Each of those roles could hold their own login, in case you do not want to use a common login page. In case you do want to use a common login page, redirect the different roles to the different route based on their role.
To be fair, i would not add a super-admin (platform admin) role to the actual frontend, thus the SaaS Application. I would create a second frontend only for super-admins (your staff) and host it in a more secure way, maybe not even facing public.
Thanks for you reply!
In short, there is only two roles, Admin (our staff) and Customer. I would like not to have them in different pages folder due to to the extra level in the route (folder).
Im totaly with you with the admin-frontend as to be protected from public, but it is the way of how to make the admins be able to change customer data. One way is to do the same logic in the admin frontend as in the customer frontend, but then i have to write the logic twice, or is there any good solution for this? The goal is to have the admins only work in the admin-frontend (also when editing a customer), but without duplicating the logic behind it. And the customers are in the customer admin.
Sorry if I'm confusing, I don't really know what I want myself xD
I understand you better now 🙂
You can create a base nuxt application holding all the components and logic you want to share between admin and customers. Your actual frontends can then extend the base repo and share the codebase.
https://nuxt.com/docs/getting-started/layers I use it myself in a SaaS service and it works like charme. We implement the "base" repo as git submodule (sometimes annoying) but i would consider a monorepo today.
Nuxt
Layers · Get Started with Nuxt
Nuxt provides a powerful system that allows you to extend the default files, configs, and much more.
Ah i will check that out! Thanks.
In your SaaS service, do you have a similar situation? With different admins?
We do. Our internal Staff is using it's own frontend, only accesible via a secure network.
And your staff can change customer data from that admin ?
It's actually even using it's own backend, to be fair.
Yes they can change some things, but its mostly read-only.
Okey! Our staff should be able do exactly the same as the customer, so "login as the client"-method that is being used today is the easy way but i really don't like it.
Do you have any advice regarding permissions (for the different pricing levels) in nuxt?
Yeah, we have that idea too. We work with something we call shared-organizations. If a customer wants direct support from the support team, we ask them to invite the supporter to their org (we do not charge a license). This gives the feeling of a super secure platform that not even we can access a customers data without consent.
We attach a license (free, pro, enterprise) to the users account or a shared organization and have a central permission checker in the frontend. We do use v-if's a lot like this.
The permission checker comes in the form of a composable.
Lovely, thank you so much for the input!
Anytime mate!