Modular access control for organizations

Context

Potential and existing customers wanted granular control over employee access, and their requests quickly gained the highest user impact score in our ProductBoard.

Rise supported five access roles and a few feature permissions, the latter requiring the Customer Support team to configure. The system needed more cohesion and flexibility to expand the company's addressable market, and meet the needs of its clients.

To address this, we rebuilt our platform as a permission-based access control system that enabled customers to create fully customized, modular roles.

Role

As the sole designer, I redesigned Rise’s access control system from wireframes to prototypes and led the design for the permissions naming and classification framework.

Permission-based access control
We enabled the creation of fully customized roles by overhauling our system to permission-based access control.

As many companies have different employees handling people management tasks the five roles Rise offered could never fulfill all the unique combinations of feature-access customers needed.

Rise was built on a role-based access control system, where features grant access based on a user's role name (similar to a nightclub with a guest list). This meant that new role names wouldn't be recognized and existing ones couldn't be configured without hard coding.

For custom roles to work, we needed to change our access architecture to check for permission values rather than role names.

In a role-based system, feature access is granted to matching role names. Since names are hardcoded, a custom role would not be recognized.

In a permission-based system, feature access is granted if you have the correct permission value. Roles are just collections of permissions to be assigned to an employee.

As customers could potentially create an endless amount of new roles and dozens of new permissions were soon to be included, we redesigned our Roles & permissions flow to allow more space for roles, and improved the information architecture of our permissions list to provide a better grouping with multiple levels of hierarchy.

Rebuilding a decade worth of product code would be too large a task for one team. Each product team understood their domain best, which made them more qualified to implement their own permissions.

Without guidance, the language and classification of permissions would be inconsistent across products, which could lead to confusion over their purpose. If we wanted teams to adopt our solution, we knew we had to build utilities to make permission creation simple.

Permission framework
We implemented a framework to allow other product teams to build their own permissions.

To provide structure for the product teams, we built engineering utilities and design frameworks so that each team wouldn’t have to reinvent the wheel.

I focussed on a flowchart using yes-or-no questions that provided permission names and classifications that would be consistent across products.

The flow chart in diagram form, the last of 5 iterations.

Framework adoption meant eliminating any future dependency on the platform team and greatly reduced the time spent on permission creation. After several weeks of strategizing and several more of development, the R&D department managed to completely rebuild our system using permission-based access control.

This success also meant all our permissions were customer-facing, meaning our Client Experience team would no longer need to spend countless hours configuring employee access.

Modular roles
We made roles modular so customers could assign them like access building blocks.

With the migration to a permission-based access control system, customers would be free to create as many unique roles as they required. At the time, Rise only allowed one role to be assigned per user. Between the seven Rise products and a growing feature list, the variations of access could lead to dozens of duplicate roles with minuscule differences. So, how could we make roles more reusable?

We redefined roles to allow for smaller scopes and to be additive, enabling customers to assign multiple roles like building blocks for wider platform access. This meant customers could manage a smaller number of focused roles that have few if any, overlapping permissions.

Groups of permissions can be added to a role through a sidebar.

Each group has a collapsable container containing editable permissions.

Employee roles can be viewed and edited from the User management page.

Roles are added and removed from the left side of this modal. The right side shows an updated snapshot of what access the employee will have when making the role changes.

Conclusion

When we started the project at the beginning of 2022, nobody would have believed that we would have rebuilt our entire access control system by the end of the year. Through the commitment of our platform team and the cooperation of the entire R&D department, we not only accomplished that goal, but we’ve also managed to make significant improvements for other departments and our customers.

8/8

All 8 products and their respective teams have adopted PBAC. This will allow them to continue developing their product permissions without Platform team intervention.

100%

100% of role and permission configurations are being handled by customers, saving our CX team over 48 working hours per year. Clients also no longer need to wait 2-3 days for access changes.

360

2 months after our beta release, 360 users have been assigned STT roles from participating organizations.