Role Based Access Control (RBAC)

I revamped Lever’s access and permissions model (RBAC), which was a high-demand, high impact request from 32 customers, totaling over $2.4MM in annual contract value. The project took 6 months start to finish, resulting in a custom roles feature that allowed customers to define and create roles tailored to their needs, achieving a 57% customer retention rate, generating over $1.2MM in gross revenue, and attaining a 75% adoption rate within 3 quarters.

In Q3 of 2023, the executive leadership team conducted a poll amongst Lever’s strategic customers, showing that 100% voted RBAC as the most valuable feature.

image showing final designs for RBAC project

Overview

I inherited this project after the original product manager left Lever, where it was then passed to a different PM, who also left Lever. Their initial hypothesized problem was around the idea of "access inflation", which hypothesized that due to too many unknowns and risks of blockers, users get the highest level of permissions by default from their orgs. This could be a potential risk for companies, since the highest level of permissions known as "super admins" or "sadmins", have access to all information on hired and non-hired candidates, including private or sensitive candidate and employee data.
‍
In addition to the above, a known core issue was the lack of available management and visibility into existing permissions and access roles assigned to employees org wide, or individual views into permissions, meaning ICs never knew the level of permissions they had, were supposed to have, or in a worst case scenario, not supposed to have.

Problem

Access and permissions were a continuous focal point for quarterly internal feedback reviews. It was consistently one of the largest categories by ticket volume and customer ACV. (32 tickets and ~$2.4M in ACV in Q1FY22 alone). Lever’s current 5 access roles are relatively complex and inflexible. Users (and most Lever employees) were unsure of what permissions each role has and which information and functionality they should/should not have access to.

We needed to restructure Lever’s existing architecture to enable customers with the “right” level of access based permissions in an effort to reduce enterprise churn and improve SMB + MM team enablement. Lever has 3 groups of market segmentation defined by company size: small/medium business (SMB), MM (mid-market), and enterprise. Customers across all segments consistently voiced their need for more flexibility in-product with available roles and access controls. Enterprise segments were more at risk to churn at time of contract renewal due to these limitations. 

Outcome

The creation of a self-serve management portal within an organization's settings, which solved our new-found prioritized problems without compromising the value add. The advanced settings hub provided an all-in-one view for admins to access all users within the platform, allowing them to view and manage users on a case-by-case basis.

Impact

Custom roles produced a 57% customer retention rate, generating over $1.2MM in gross revenue within 3 quarters of release, and additionally a 75% decrease in support tickets related to access and permissions.

What we were working towards

Jobs to be done, outcomes, and how we measured the success of our anticipated outcomes.

Job to be done

Permissions security

First, enable users to view their individual assigned permissions. Then, enable org admins to access, view, and manage all existing user data involved with org access and permissions to gain confidence in product security.

Job to be done

Flexible permissions

Allow customers to customize roles to fit their business needs no matter their segment, privacy restrictions, or persona through a self-serve enablement portal to view, build, and manage permission sets and role assignments.

Outcome

Outcome: Wider adoption

With the right permissions, users can complete the jobs to be done within their role, without having to exit Lever or rely on others that currently create blockers in their daily flow, increasing product engagement and org-wide adoption.

Outcome

Outcome: Decrease Churn

Lever started with SMBs, and those SMBs have continued to grow beyond our product capabilities, leading to an increase in customer churn. This implementation will allow Lever to scale alongside customer needs no matter their stage of growth.

Measuring Success

Decrease churn

Lever's ability to evolve alongside our customers—from SMBs to MM to Enterprise—reduces churn risk. As businesses enter new segments, they enhance internal security and privacy. Flexibility in maintaining or converting enterprise contracts is crucial for adapting to these shifts.

Measuring Success

Success metric: ARR retention

Enterprise Sales shows alarming data on the number of orgs who plan (or have already) to cancel their contract at the time of renewal due to their frustration with the lack of flexibility in our permissions model.

Role based access and permissions

Access roles

Access roles identify groups of permissions that apply to a user within an org. This is usually based on their title and job function (or persona). Access Roles go from limited capabilities to 100% unrestricted access, including all employee and candidate details.

It was unclear to admins which access groups were the best match for their employees which resulted in concern and distrust in what they were providing. Some concerns included employees having access to hired employees information, salary details, confidential information, access to their own candidate profiles pre-hire, including notes written about their interview performance, and more.

Lever has 5 access roles: Sadmin (super admin), Admin, Team member, Limited team member, and interviewer.

a visual representation of access roles

Permissions

Permissions are the individual features or functions users can or cannot access within the product. Access roles come with their own set of permissions by default, but users can layer in additional permissions for sensitive or private content on an as-needed basis.  Permissions were too rigid due to the inability to customize, making it difficult for customers to find the right fit amongst Lever's 5 pre-defined role buckets.

For example: if one employee met the criteria for an access role, but one permission was missing required for them to get their job done, the only way to grant that permission is to assign the access role one tier higher. This would provide that employee access to additional areas of the tool that might be confidential, thus compromising security.

a visual representation of the existing access roles

Personas vs access roles

One of the challenges during research was how Lever employees used “personas” and “access roles” interchangeably. This caused confusion with product owners as they thought personas were individual, company defined entities around our users "jobs to be done" directly mapped to how our product defined access roles within the product.

However this was not the case as personas didn't exist yet! Roles were the closest thing product had to understanding how customers might be using the product, but created risk in feature planning since neither personas nor role use cases had been tested or validated.

a visual representation of access roles grouped by user type

Process

02

Roles and permissions

Researching Lever's RBAC architecture for the access model, mapped permissions sets, and private data. Being fully informed of the relationships between roles and existing permission sets as well as how we defined and mapped those  to each user was crucial to success.

03

Lever's users

Lever did not have known or defined company level personas. Product had  a list of 22 different job titles involved in the hiring process without any defining factors to them. I needed to understand how users role tied to a set of permissions, and how those roles/titles changed based on company size and team structure.

04

Competitive analysis

I spent time reading through our top competitors configuration documentation to understand what type of roles they offered and how that mapped into their system, back to their users. Being able to pull themes from this research enabled us to rule out potential paths and focus in on the key areas of our solution.

05

Internal users

I interviewed an internal team of recruiters, customer success managers, and implementations teams to validate design direction, hypotheses, and discuss how customers approach roles, titles, and permissions, as well as their blockers and biggest pain points today.

06

External customers

After combining all of the above into potential path forwards and high fidelity mockups, I needed to validate the direction we were headed and test solutions with our customers. I spoke to 10+ CSM, recruiters, and talent operations teams across all market segments to validate our original hypothesis.

Insights

With internal and external customers I validated more within the default permission sets hypothesis: "Do user personas and their jobs to be done tie directly to product access?" I inquired more on what users considered “safe” and necessary in a listed group of role titles and associated job functions as well as private permissions, or the things users may feel are necessary to get their job done, but risky to include as a "default" without level or title considerations.

I synthesized competitor permission models and found that the common theme amongst all competitors was the way they structured their permissions. It was less focused on granular job titles and more focused on what users are doing in the product or what users need to see and manage.

  • Use case 1: Manage product or platform for users. The highest level of access amongst all competitors was known as the "org admin" who fell into this use case. They are in charge of managing users access, profiles, statistics, integrations, in-app stores or marketplaces, payments, compliance, and product add-ons. Products either limit or customize access if the role is defined as someone who manages the entire ATS software.
  • Use case 2: Manage the talent and hiring process. These user roles are typically identified as "standard", or "job admin". Each company offers varying “hiring roles” based on its model. Greenhouse segments permissions specifically on the assigned title once assigned a job. Others like ICIM group all hiring roles into one permission group called “full access users". These default access roles users are grouped into for platform permissions usually require an additional layer of permissions group assignment once a user is either assigned a specific job opening or to a team.
  • Use case 3: Interview and review candidates. Typically labeled as “interviewer”, “basic”, “limited”, “employee”.  Usually the most “limited” access role assigned to users who don’t actively participate in platform/org management or the hiring process but may conduct interviews or panels with incoming candidates. Users with this permission participate in providing feedback, rating candidates, and uploading referrals.

Customer research unlocked a key factor to our success.

A trend amongst enterprise orgs was the limited amount of "super admin" roles allotted within the platform. Due to enterprise security and compliance concerns regarding employees access with each tier Lever offered, they decided to restrict all access available to talent and recruiting teams, creating entirely new workflows that required manager approvals for users to view or access application details and job postings. This created hours of extra work and long delays for employees that need to manage the candidate pipeline, slowing down their hiring process and unfortunately in some cases, losing talent due to long waits and the inability to negotiate compensation.

Testing details

example screen from usability testing: ui shows add new user flow
example screen from usability testing: ui show: add permissions flow

The "add new user" screen in the onboarding flow containing role and permissions assignment.

Custom levers added for users to gain visibility into each individual permission included within a role, the ability to remove as needed, ability to group permissions by location, office, or department, and added visibility into private permissions.

I led a session between myself, stakeholders, and my PM to re-strategize our MVP approach. We used this session to discuss tradeoffs and ideal solution from a business and customer needs perspective given our newly uncovered insight. We felt it was crucial to pivot away from mapping persona to permissions 1:1 until we could integrate with an HRIS tool and automate the collection and mapping of user details to each role. This would provide a more targeted and precise approach when enabling automated permissions provisioning, rather than needing to build the backend model from scratch during our MVP.

Knowing what customers defined as "success" for our permissions model, it was crucial to offer access roles that matched how their org approached talent operations and recruitment. We wanted to enable our customers as quickly as possible while staying on track for our MVP release date.  

Custom permissions was a beneficial move that had business stakeholders excited, customers excited, and kept our release on track and aligned with business outcomes. Our solution would additionally allow us to scale easily as we move into phase 2 and beyond.  

Results

$1.2MM

Revenue retention

57%

Customer retention

75%

Reduction in support tickets

2,200

Unique custom roles created