Building a Permissions Framework

Building a Permissions Framework for RBAC

Flo is a comprehensive product suite that includes an applicant tracking system, event hosting and management, networking capabilities, and a double-sided marketplace connecting legal firms with aspiring attorney’s.

Role:
Product Design Lead

Responsibilities:
Strategy, north start vision design, team managment, stakeholder management, engineering cross collaboration

Status:
Released Q1 2025

Background

At the start of this project, our product lacked a formal permissions framework, and the only access granted was for admin roles. Non-admin roles were unable to log in , and we used a magic link to allow them to access specific pages or features. This approach had several limitations: non-admin roles lacked a structured navigation and had to save individual links for each feature they needed to access, creating significant friction and user frustration.

Additionally, there were no clear distinctions between feature-level permissions and organization-level role permissions, which made scaling the user base for legal firms difficult. Our main objective was to design a robust permissions framework that would support RBAC, allowing firms to scale their users and manage access efficiently.

Project Terminology

Defining and establishing consistent language for the project

Discovery & Research:

I began by diagramming various permission frameworks from other successful SaaS applications, researching best practices and identifying what might work for our product. To collaborate and align with the broader team, I led a workshop with product, design, and engineering to weigh the pros and cons of different frameworks, considering factors like scalability, ease of implementation, and user experience.

During this workshop, we also discussed how to structure permissions: feature-specific permissions vs. organization-level role permissions. A key concern was how to make the system scalable enough for growing firms while keeping it simple for administrators to configure.

Strategy:

Given the tight timeline and dependencies, particularly the need for a functional permissions framework to support our Summer Program feature, we defined a north star and worked backward to prioritize the most critical elements for an MVP. The Summer Program required non-admin roles to log in and for admins to define user permissions related to managing and viewing program features.

We decided to kick off with a rapid 1-week design sprint, focusing on what needed to be done to deliver the MVP. After this, we spent the next two weeks conducting moderated user interviews to validate our assumptions and refine our approach..

Solution

Working in close collaboration with engineering, we began breaking down the work into manageable chunks and setting clear priorities. I led the handoff meeting, where we discussed trade-offs, outlined what was absolutely necessary for the MVP, and determined which features would be fast-follow work versus future enhancements.

Outcome

This permissions framework laid the foundation for future role-based access control in our product, enabling legal firms to scale users as their businesses grew. With the Summer Program feature now able to leverage this framework, we successfully provided both admins and non-admin roles with flexible access to the product’s features while maintaining a smooth user experience.