DigitalOcean | Cloud Computing & HostingIAMAccess control
RBAC - Custom Roles
Custom roles further DO Simple RBAC. Teams can define, create, and manage roles with the permissions they want, that "just work", in a flow that stays intuitive and minimally complex instead of echoing the overwhelming IAM patterns users know (and loathe) from AWS and GCP.
Problem
Users need more granular access than predefined roles alone. The risk is repeating what they dislike elsewhere: dense permission lists, unclear dependencies, and combinations that set them up to fail.
Solution
Provide a simple experience where users can create custom roles with the permissions they desire and easily assign those roles to their team members.
Goals
Keep access secure with no surprises (least privilege), prevent failures by not allowing role definitions that would break in use, and keep creation simple to meet needs of enterprise security-focused users.
Launch impact
Results
After launch, custom roles saw strong early adoption: nearly 5,000 assignments across thousands of teams, with measurable uptake in enterprise accounts.
~0
custom roles assigned to users
0
teams using custom roles
0%
usage among enterprise teams
Scope & collaboration
IAM design lead on the next chapter of DO Simple RBAC
UXR partnered throughout: interviews and usability to pressure-test creation, required and related permissions, and assignment flows; joint synthesis on where people struggled with other clouds; and ongoing sessions so findings fed prototypes and launch readiness.
0
user interviews (with UXR)
0
usability participants (prototype sessions)
- My role
- IAM design lead for end-to-end UX: creation, required and related permissions, assignment paths, and post-create management.
- Research
- 13 interviews and 9 usability participants across prototype sessions, plus ongoing IAM/RBAC session summaries.
- Artifacts
- PRFAQ for RBAC phase 2, custom roles workbook, permission naming and categorization references, and the shared IAM spreadsheet used across product areas.
Research
What people told us
Users consistently compare DigitalOcean to AWS, Azure, and GCP and cite complexity as their biggest frustration. Too many permissions and unclear documentation were the most common complaints. They want granular control, but not at the cost of simplicity. CRUD checkboxes were the most commonly requested pattern, with several users describing exactly that before even seeing the prototype. The custom role creation flow tested well, with the majority rating it 7/7 for ease-of-use.
Usability focus
Most participants went straight to granular permissions instead of templates. When Basic Role templates sat above the list, people read them as mandatory or confusing to edit and simply did not seem too useful, so templates moved into an accordion as an optional starting point. Clone role was a praised feature by testers and the clearest shortcut for similar roles. Project-level access came up unprompted in almost every session.
Research findings
In July 2024, 9 prototype sessions on custom role creation and multi-role needs, with participants from hobbyists and SMBs to enterprises managing 400+ users.
- Project-level access. Came up unprompted in almost every session. Many skip the use of DO's projects today because it does not govern permissions.
- Creation flow. Most rated 7/7 for ease of use. CRUD checkboxes matched what people asked for before they saw the UI in testing. Participants surprisingly has pleasant reactions to the required permissions modal, which completely took me by surprise.
- Templates and assignments. Basic Role templates read as required until they lived in an accordion. Only 2 of 9 users needed multiple roles per user; most expected project-level rules or custom roles to cover their needs.
- Simplicity. Participants kept referencing the mess of AWS and asked that DO Simple UI stay intact as RBAC depth grows.
Core experience principles
I created these core principles to guide both myself and team members in order to establish alignment and ensure our decisions reflected our goals and user needs for custom roles.
No surprises
Users should not be surprised they have more (or less) permissions than expected. This also follows the Principle of Least Privilege. Language and selection stay plain so each permission reads like what it actually does in the product. Permissions are bundled and clear so admins are never left guessing what their role can do once they hit create.
Prevent failures
In the spirit of DO Simple, users should not be able to create any custom roles that would result in failures. The experience sets them up for success. Additionally, this lessens UX and technical burdens by avoiding extra experiences to handle errors due to the wrong combination of permissions.
Simplicity is everything
In research, users compared this work to other clouds and said again and again how much they dislike those role experiences, with too many permissions and too much complexity. CRUD-shaped coverage of core resource types, paired with a simple creation path, balances granularity with a flow light enough to assign to teammates with confidence.
Experience & communication
Experience & communication
Creating a custom role
Creating a new custom role uses a 3-step flow: name the role and choose primary permissions (with a required-permissions modal when needed), optionally add related capabilities, then optionally assign the role immediately.
Users mostly jump into the granular selection of permissions, but I crafted a selection of templates from our basic roles (except Owner) or other custom roles they may have already created to jump start the selection process if the user wants some direction. The granular selection of permissions provide search and grouped headers tame long resource lists where search and grouped headers tame long resource lists where most actions are CRUD-shaped but some include extras like assign or access cluster.
Required permissions
When a permission has required dependencies, it opens an accordion that lists what is required and why. Read permissions are also required by any action outside read and are selected automatically, because the UI is not usable without them. If the user still misses a required permission, we show a modal before we add it so nothing is added without them knowing.
Related permissions
Related permissions differ from required permissions; they are suggested, optional permissions. We surface permissions that are connected to what they already picked in the previous step but are not required for the product to work. For example, backups pair well with a Droplet but are not required for a Droplet to be created.
In testing, related permissions were very helpful: people added many of them and built more functional roles to assign to their team members without bundle bloat.
Assign during creation
While creating a custom role, the person creating it can assign it to a team member immediately to reduce mental workload and steps.
Outside of the custom role creation experience, users reassign roles in team settings with the change role modal, which supports both basic roles and custom roles.
Overview after creation
After creation, the role access tab lists custom roles with both control panel and API namespaces in the table; from there they can edit, clone, or delete (delete only when no one is still assigned, otherwise we send them to team settings to change roles first).
See it on DigitalOcean
Official launch post on custom roles: what they are, how they work, key features, and how teams use them with least privilege.
🧑💻 User voice
Representative feedback from usability tests and user interviews on custom roles and related admin needs.
“As account owner / super admin, would like to be able to create and assign a lower account admin role that would be able to invite team members and assign permissions but not remove them.”
“Maybe good role for someone who needs to monitor, an intern, consultant, etc. But would want to make sure they can't see secrets or customer info in DBs.”
✨ Opportunities
To meet baseline user expectations of RBAC, our work does not end with custom roles. Users expect project-level conditions. This was asked of us over 90% of the time, with many stating that custom roles are not useful to them and they will not use the feature until they can restrict those roles to specific projects. Some people mentioned wanting to restrict roles to tags or even to very specific resources, but the overwhelming majority want to limit roles to projects.
People also expect to assign more than 1 role to the same user. That expectation ties directly to project-level scope: they want different permissions for the same person in different projects, which implies multi-role support. In interviews, 1 participant described wanting a junior engineer to have broad permissions in a sandbox project but very limited access in production. Examples in that vein surfaced repeatedly in interviews and usability sessions.
Sadly, previewing the role on the platform before finalizing was descoped. In research, participants said it would have been very useful to see how permissions would behave before committing, and some felt unsure what the final results would be without being able to try it on the platform first. Bringing preview back into the fold in a future release remains a clear opportunity to close that gap.
✍️ Peer feedback
“AJ was an exceptional partner on the launches of Custom Roles, SSO, and Session Management work for DigitalOcean's cloud platform. The team had to pivot directions multiple times, and each time AJ has stepped in and effectively "saved the day" with thoughtful, well-structured solutions.
Her designs are consistently customer-centric, balancing technical rigor with what will create the best possible user experience. I especially appreciate AJ's ability to recommend clear priorities, highlighting which enhancements will drive the most value and where we can responsibly cut scope to deliver on time.
Beyond the excellent quality of work, AJ brings a collaborative, positive energy that elevates the entire team. Her partnership has been invaluable, and I'd happily work with her again on any complex, high-impact initiative.”