BlogDesigning Modern Enterprise SaaS: Users and Access Management

Our SaaS Administration series examines the design and architecture of modern SaaS solutions.  As a follow-on to our first installment, this article will examine the most common need in SaaS administration:  admitting users into the application and defining what they can (and can’t) do.

There are myriad ways to on-board to a SaaS application.  Your design choices depend on the business’ policies, strategy, customer acquisition plan, etc.  Due to the complexity of variation and nuance in our design choices for different clients, we will paint a picture for you in broad strokes.

User Management

What would a SaaS app be without users?  We are so accustomed to working in our day-to-day SaaS apps that we often forget: someone had to plan how we were onboarded.

B2C and B2B SaaS offerings largely differ in terms of onboarding users.  The B2C variety acquires users one-by-one, with each registering through a standard email verification process to create and activate their new account. The B2B variety leverages adoption by a business enterprise to gain users within the company, with each user registering via an account activation process initiated when a SaaS administrator creates an account.

It is helpful, especially in the B2B scenario when the admin panel supports a variety of user creation scenarios.  At the base level, an administrative user from the business must be able to add new users one-by-one.  In addition, bulk import of user accounts from a spreadsheet can significantly speed up the onboarding of new customers.  Finally, the SaaS admin panel may support delegation of all user account management to certain users from the customer’s organization.  This self-service model is the norm these days, reducing the administrative load on the SaaS business’ customer service by handling only exception cases.

In both B2B and B2C SaaS apps, the identification of the user may be handled by an identity provider (IDP) such as Google, Facebook, or internal systems that support SSO (single-sign-on), such as from Microsoft 365.  In either B2B or B2C case, this smooths the onboarding path for new users.  The specific IDPs available (system-wide, or on a per-customer basis for B2B offerings) may require configuration in an admin panel.

In summary, while not an exhaustive list, admin panels often support these capabilities:

• View, search, filter the list of users
• View, create or edit a single user
• Activate / deactivate one or more users
• Bulk user import
• IDPs and SSO configurations

Access Management

With User Management properly designed, the most important need is establishing what users can do in the app.  Regular users of a SaaS application are not permitted, typically, to use all capabilities of the platform. Instead, this user is limited to use only the features enabled at onboarding.  How is feature access, in this case, enabled?

Permissible or accessed actions are simply called permissions.  There are many standard schemes to regulate user permissions in SaaS.  One of the most prevalent schemes is role-based access control (RBAC).  RBAC focuses on defining a role as a collection of permissions available to users assigned to that role.  Admins can define however many roles are necessary, each with their own corresponding set of permissions.  

RBAC provides many advantages.  The role-permission model is extremely flexible, especially when each user can be assigned more than one role.  RBAC also serves to future-proof the SaaS when new capabilities are introduced.  For instance, when a new feature is available, its associated permissions are simply assigned to one or more existing roles, and now users in those roles gain access to the new feature.  RBAC, when managed entirely through the SaaS admin panel, allows the business to roll out (or roll back) features quickly without development intervention.

The admin panel for an RBAC SaaS normally supports on-the-fly role creation, and management of permissions for each role.  Excellent UX design recognizes that permissions must be defined carefully, such that they function independently in the UX.  In a faulty design, inter-permission dependencies will quickly make RBAC very complex, and lead to complicated workflows and bugs.

RBAC access management goes hand-in-hand with user management because every user in a SaaS must have at least one role, typically assigned when each user is created.  The role of a user may be to create and manage other users, which is how admin users are “born”.  Every role beneath the super / system administrator (generally the role with the highest permissions in the SaaS) is usually defined and managed in the UX-designed admin panel.   

To summarize, admin panels often support these capabilities:

• Role definition
• Permission assignments to roles
• Assignment of roles to users
• Viewing users by role

Closing Thoughts

User and access management are core needs of any SaaS application, and therefore core features within the admin panel designed by you and your UI/UX experts.  Both the user onboarding method and the permission scheme (RBAC or another) will heavily influence the UX design of a SaaS application.  UX designs must simplify the inherent complexities when accounting for variable user permission access. Otherwise, the redundant screens of a poor design will create a bulky and confusing user experience.  UX needs to take a wholistic view of the SaaS application which includes the underlying admin capabilities to produce the best overall user experience for all of your users.

Look for the next article in our series which will cover Content Management.

Photo by Pedro Ramos on Unsplash