Rethinking Roles and Permissions

The challenge was to move beyond rigid user roles and introduce a flexible permission structure without disrupting existing workflows or creating unnecessary migration complexity.

Adding a dedicated Credit Card Admin would solve the immediate request, but it would leave the underlying problem untouched. Every new administrative responsibility could require another role, making the system increasingly difficult to maintain.

I set out to achieve three goals:

Separate responsibilities from roles: Allow access to be assigned based on areas of responsibility, such as Credit Cards, Benefits, Settings, and Integrations.

Preserve existing workflows: Introduce the new structure without breaking established permissions or requiring disruptive changes for existing customers.

Design for future growth: Create a modular architecture that could accommodate new access rights while minimizing the complexity of future migrations.

The goal wasn't to introduce more roles. It was to create a structure that wouldn't need to be redesigned every time the product expanded.

I started by mapping the existing roles, permissions, and dependencies across Circula's products to understand how changes in one area could affect others. I then analyzed competitors and established SaaS platforms to understand how they structured roles and access rights.

Rather than designing another predefined role, I explored a modular structure that separated administrative responsibilities from access rights. This required considering not only the immediate Credit Cards use case but also how the system would evolve as new products and permissions were introduced.

I combined customer interviews, card sorting, and close collaboration with senior Backend Engineers to validate the direction and understand technical constraints. Their expertise was essential in navigating the existing architecture, evaluating implementation feasibility, and designing a solution that could evolve without disrupting existing functionality.

Throughout the process, preserving existing access rights was a non-negotiable requirement. No user should lose permissions as a result of the migration. At the same time, the architecture needed to accommodate future access rights without introducing unnecessary migration complexity.

What began as an investigation into a single feature request evolved into a broader initiative that I brought to Product and Engineering leadership for alignment.

To understand how customers approached access management, I conducted interviews with administrators and finance professionals, followed by a card-sorting exercise exploring how they grouped different administrative responsibilities.

The research confirmed an important assumption: users think in terms of responsibility areas, not predefined roles.

Participants naturally grouped permissions around activities such as managing Credit Cards, Benefits, Settings, and Integrations. Credit Card management emerged as a distinct responsibility, while Settings and Integrations were more closely associated.

These findings reinforced the direction toward a modular permission structure, allowing organizations to delegate responsibilities without granting unnecessary access. They also provided evidence to support the proposed approach in discussions with internal stakeholders, helping build alignment around a shared understanding of customer needs.

Rather than forcing customers to adapt to Circula's internal role definitions, the goal was to create a structure that reflected how responsibilities were distributed within their organizations.

The solution introduced a modular permission structure that separated administrative responsibilities from unrestricted platform access.

Separating ownership from responsibilities

I proposed distinguishing between two types of administrators:

Admin: The existing role, retaining full access to the platform. Only Admins can invite other Admins or Managers.

Manager: A new role with configurable access to specific responsibility areas, such as Credit Cards, Benefits, Settings, and Integrations.

This allowed organizations to delegate administrative tasks without exposing unrelated functionality.

Designing for backward compatibility

Introducing a new permission structure couldn't come at the expense of existing customers. 

I designed a migration approach that preserved all existing access rights. Current Admins would retain their permissions, while the new Manager role could be introduced incrementally, starting with Credit Cards.

Customers could then decide how to redistribute responsibilities, choosing who should retain full administrative access and who should receive more limited permissions.

The modular structure also meant that future access rights could be added without redesigning the role system or repeatedly migrating existing users.

Aligning stakeholders around a shared solution

The proposed architecture required agreement across multiple product areas, each with different requirements and technical dependencies.

I presented the research findings, permission structure, and migration strategy to stakeholders across Product, Engineering, Finance, Sales, and Customer Support, addressing concerns about complexity, scalability, and existing workflows.

The direction was approved by the CTO and Head of Product, establishing a foundation for introducing more granular access control across Circula.

What started as a request for a dedicated Credit Card Manager evolved into a broader redesign of Circula's permission architecture.

The initiative delivered three important outcomes:

A scalable permission model: A modular structure that supports new responsibility areas without requiring additional predefined roles.

A migration strategy that protects existing customers: Existing access rights are preserved, while organizations gain the flexibility to redistribute responsibilities.

Cross-functional alignment: The proposed architecture received approval from the CTO and Head of Product, with the Credit Cards Manager prioritized as the first implementation.

Beyond the solution itself, the project brought visibility to an underlying architectural problem that had remained unresolved as the product expanded.

By addressing the root cause rather than introducing another isolated role, I helped establish a foundation for more flexible and maintainable access management across Circula.

This project was one of the most intellectually challenging and rewarding experiences I've had in my career. What initially appeared to be a simple feature request turned into the process of untangling a complex system of interconnected roles, permissions, and dependencies.

My biggest takeaway was the importance of recognizing when a local problem is actually a symptom of a larger structural issue. Adding another role would have been easier in the short term, but it would have introduced more complexity in the long run.

I'm particularly proud of taking the initiative to investigate a problem that hadn't been prioritized, making its implications visible across the organization, and developing a solution that balances existing customer needs with future scalability.

For me, the most satisfying outcome was finding a relatively simple and elegant structure for a problem that initially seemed overwhelmingly complex.