Designing clarity for enterprise identity and access.
I led the redesign of Centralized Access Management at DevRev, separating identity from permissions without disrupting customers already live on the platform.
What began as a request to improve a confusing Roles UI uncovered a deeper architectural problem: one concept, Groups, was responsible for both organizing people and controlling access. The interface wasn't the real issue. The underlying information architecture was.
The challenge wasn't simply to redesign a screen. It was to redefine a foundational system while ensuring every existing customer retained exactly the same access throughout the transition.
RoleProduct Designer
Collaborators1 PM, 3 Engineers
Year2025 · DevRev
The problem
DevRev used Groups for two fundamentally different purposes — organizing people into teams, routing lists, and conversations, and granting permissions across the product. Both concepts lived in the same data model and shared the same interface. As organizations grew, administrators could no longer distinguish between a group that represented organizational structure and one that controlled product access. Editing the wrong group could unintentionally change permissions.
The issue first surfaced while investigating why customers struggled to configure roles. What initially looked like a usability problem quickly revealed a structural one: the interface accurately reflected a model that had outgrown itself.
That conclusion became even clearer when multiple enterprise customers independently described the same pain point.
"We need a way to differentiate privilege groups from ticket-routing groups."
Velocity Global2024
"We want a clearer display of which group or role a user actually holds."
Spintly2024
"Our groups are overloaded across privileges, team access, and license management."
Spotnana2024
Challenges & how I solved them
Separate identity from permissions without breaking existing behavior. Groups had quietly handled both identity and access for years. Untangling those responsibilities meant redesigning a foundational platform primitive rather than introducing another feature. Before proposing solutions, I worked closely with engineering to understand how deeply this behavior was embedded across the system.
Design a permission model that could scale beyond CRUD. Enterprise organizations rarely fit into simple permission models. Access often depends on context, specific projects, support teams, records, or even individual fields. The solution needed to support increasingly granular permissions without overwhelming administrators.
Approved, this looks good to ship.
Customer nameJack Wildfire
PriorityP2
Billing information•••• •••• ••••
Migrate live customers safely. This was not a greenfield redesign. Existing organizations were already relying on the current model to manage production access. Rather than forcing customers through a disruptive migration, I designed a "Mark as Role" flow that promoted existing permission groups into the new Roles system while preserving every assigned user and permission. The rollout happened gradually, allowing larger customers to transition with confidence.
What did we ship?
Instead of asking one concept to do two jobs, we introduced two dedicated systems: Groups became the source of truth for organizational structure, covering teams, routing, and collaboration, while Roles became the dedicated system for permissions. The separation gave administrators a clearer mental model without disrupting the workflows they already knew.
The shipped Roles list: built-in templates, custom roles, and their status, all in one place.
The redesigned profile panel: groups and roles shown together, finally answering who has access to what.
Impact
A system customers could finally read. Admins can now see, at a glance, exactly which groups someone belongs to and which roles they hold, closing the exact gap Spintly and Spotnana flagged.
Granular control without complexity. Conditional, field-level access is now something admins configure directly, not something that requires backend intervention, a capability few products in this category offer at this depth.
Zero-incident migration. Rolled out in phases across an already-live customer base with no security incidents and no support tickets raised during the transition. The feature merged into the product cleanly.
Future scope
Migrating from a groups-only world doesn't happen overnight, even with a non-disruptive path in place. A guided onboarding tour introduces existing admins to the new roles system after launch, walking them through the separation of roles and groups and the full set of permissions now available.
.svg)
