Rearchitecting Permissions to Reduce Risk and Retain $1.2M in Revenue

Overview

Lever is an applicant tracking system (ATS) and talent acquisition suite designed to help companies streamline their hiring process. It enables teams to source, nurture, interview, and hire candidates in one collaborative platform. With built-in CRM capabilities, Lever also helps companies build strong talent pipelines and improve long-term candidate engagement.

Role-based access control (RBAC) defines what users can see and do in a platform based on their assigned roles. Lever's original permissions model offered five predefined roles, with no flexibility. This worked for smaller teams, but as customers scaled, so did the complexity of their hiring operations. The system couldn't account for nuanced responsibilities across coordinators, hiring managers, and recruiting partners.

To bypass blockers, customers routinely assigned users Super Admin access, exposing sensitive data like compensation, interview feedback, and secret notes. This wasn't just a security concern, it was causing real workflow friction, trust breakdowns, and escalating support tickets across mid-market and enterprise accounts. This redesign aimed to modernize and scale Lever's permissions systems, moving from rigid roles to a flexible, admin-controlled model that could adapt to teams of any size or structure.

This work led to a custom permissions portal that gave platform admins—typically IT team members—full control to add, manage, or remove user permissions. It provided a 360° view of all assigned roles and their associated permissions, eliminating ambiguity and confusion around who had access to what.

Why this mattered

By Q1 FY22, Lever had logged 32 permission-related tickets tied to blocked workflows, over-permissioning, and role confusion, impacting $2.4M in at-risk revenue. Support teams were overwhelmed, and enterprise customers were losing confidence in Lever’s ability to scale with them.

• Misalignment between internal language and user behavior: Without validated personas, teams defaulted to using access roles as a stand-in for user needs—leading to misinformed planning and unclear ownership boundaries.
• Misuse of persona versus access role: Lever employees often confused “personas” and “access roles”, using these terms interchangeably, leading to misalignment in product understanding. Product owners assumed that personas (user archetypes tied to specific “jobs to be done”) were directly mapped to how access roles functioned within the platform. In reality, no validated personas existed, leaving access roles as a proxy for understanding user behavior.
• Over-permissioning due to rigid role structures: Customers were forced to assign Super Admin access to unblock basic workflows, creating security risks and growing mistrust in the product’s flexibility.‍
• Fragmented mental models across teams: Sales, CS, Security, and Product each had different assumptions about what access should look like, creating friction in defining scope and success metrics.‍
• Lack of visibility and control for admins: Admins couldn’t easily understand or adjust access across their teams, leading to confusion, support escalations, and risk exposure.

What I did

I led this initiative end-to-end, shaping both the strategic direction and execution. My process included:

• Foundational Research: Conducted a permissions audit and customer interviews to understand task-role mismatches. Mapped real job titles to required permissions and workflows.
• Market and Technical Analysis: Analyzed how competitors like Greenhouse and Workday approached RBAC. Partnered with engineering to explore the technical debt tied to Lever’s existing roles and enforcement logic
• Strategic Alignment: Facilitated workshops with Sales, CS, Product, and Security to align on MVP scope and future roadmap. Focused the initial release on unblocking critical workflows, while setting a path for deeper enforcement layers.
• Design & Validation: Introduced a modular Custom Roles builder with permission previews and grouped access levels. Ran 3 rounds of usability testing with real admins, iterating on visibility, naming, and mental models.
• Systematization & Rollout: Designed reusable system patterns for access tables, grouped permissions, and admin workflows. Authored training for internal teams, documented edge cases, and contributed to the legacy role migration strategy.

Research insights

Research made it clear this wasn’t just a technical gap, it was a trust issue. We interviewed 10 customers and mapped 22 unique job titles to real-world tasks. Existing roles didn’t reflect how teams actually worked. Coordinators were being given admin access to unblock scheduling. Hiring managers had visibility into sensitive notes meant only for recruiters.

We kicked off with a series of cross-functional interviews—support, CX, implementation specialists, and existing admins. Across the board, we heard variations of the same pain points you'll see highlighted here.

• “I have no idea what this person can actually do with the access I’m giving them.”
• “We had to file a ticket just to make a small change for one department.”
• “It’s too risky to test or tweak permissions because I don’t want to break anything.”

From there, we audited

• Internal documentation and support ticket trends
• The default access groups and their assigned permissions
• Comparable platforms (e.g., Greenhouse, Workday, Rippling) for inspiration

These insights led us to map core use cases and personas, from small hiring teams to global recruiting operations, and begin modeling how our permissions system would need to evolve to serve all of them. Customers wanted control, but not complexity. They needed flexible role configuration without turning into full-time system admins. At the same time, internal teams needed clearer boundaries to prevent escalation loops and workflow hacks.

Competitive analysis showed that enterprise buyers were gravitating toward platforms with granular access control. But those platforms often sacrificed usability. We saw a clear opportunity: build a system that gave teams precision and clarity, without increasing friction.

What we shipped

Sometimes the most robust, high-impact work results in just a handful of screens, but that doesn’t make it any less meaningful. In this project, the real value came from bringing clarity and structure to a deeply complex, systemic issue within Lever’s software—shaping how the platform scales for teams of all sizes.

We delivered a scalable, self-serve management portal embedded directly into org settings, empowering admins to manage user access without relying on support or engineering.

The new permissions hub provided full visibility and control through a centralized, intuitive interface. Admins could view all users, assign or revoke roles, and adjust access case-by-case. It preserved Lever's simplicity while unlocking the configurability enterprise teams needed. In the future, roles will be auto-provisioned through the HRIS, and the permissions hub will serve as an optional space for edits or visibility, no longer a required step for updating org changes to user access.

‍

Our MVP designs solved for the following

• ‍Reduce risk and make it scalable: Enable syncing with organizational HRIS tools like Workday or Rippling, ensuring access permissions stay aligned with employee status, role, and org structure as companies grow.
• ‍Make users think less: Leverage existing data, such as role, level, and department, to intelligently suggest appropriate permissions and reduce guesswork during setup.
• ‍Make it easy: Design for moments of confusion by offering just-in-time guidance and clear pathways to support, so users feel confident managing access without needing to escalate.
• ‍Make it simple: Apply recommended permission sets automatically, while still giving users the flexibility to customize as needed, balancing speed with control.
• ‍Make it flexible: For companies with multiple teams, departments, or locations, admins can now get as granular as needed— customizing permissions to match how their organization actually operates.
• ‍Make it clear: Show the users exactly what permissions they’re granting, whereas the previous experience only listed access titles with little insight into what they’d be giving individual users. Instead of a one-size-fits all approach per access group, admins can toggle on or off individual permissions as needed.

Results & impact

The launch of custom roles played a pivotal role in preserving $2.4M in contract value and contributed $1.2M in retention revenue by resolving a key blocker for large-scale customers. Within three quarters, the feature achieved a 75% adoption rate, validating its alignment with customer expectations around control and configurability.

Just as important, this work shifted how Lever was perceived in competitive evaluations. We went from “not secure enough” to being considered a scalable, enterprise-ready platform, especially in late-stage deals involving procurement, security, and IT review.

It also gave internal teams a foundation to move faster: product, legal, and customer success could now rely on a consistent permissions framework, reducing cross-team ambiguity and setting the stage for advanced functionality like audit logging, HRIS sync, and region-based access governance.

Reflection

This project reinforced that access control isn’t just a technical problem — it’s a product trust problem. Designing for flexibility meant deeply understanding both user behavior and long-term system complexity. Success wasn’t just measured by adoption or retention, but by how invisible the friction became.

It also marked a shift in how I approach platform work: moving from feature delivery to infrastructure thinking. I wasn’t just solving today’s ask — I was setting up the conditions for Lever to scale with confidence across regions, roles, and regulations.