Designing a Multi-Role Access System for Complex Private-Market Teams
Overview
When you work in private markets, "access" isn't just a technical setting, it's trust. It determines who can see sensitive investor data, who can move money, and who has the context they need to do their jobs. But in reality, teams don't work in neat boxes. One person might handle investor services for a couple of funds, support fund counsel on a separate SPV, and still need admin-level access for their organization.
Before this project, Vega didn’t have a flexible way to express that. We needed a system that reflected how people actually work and not how org charts are drawn.
I led the design of a new Role & Fund-Level Access Management model: a simple, human-centered way to give people the right access without overwhelming the admins managing it.
Goal
- Support multiple roles per user with fund-level scoping
- Provide clear visibility into user access
- Prevent over-permissioning with safety controls
- Scale from 5 to 200+ funds
Outcome
- Under 4 minutes to configure new user access
- Reduced permission errors with clear previews
- Increased admin confidence with safety controls
The Problem
Teams within private markets have overlapping, constantly shifting responsibilities. An Investor Services team member might be all-in on two funds, occasionally support a side vehicle, and never touch the rest. Auditors may need temporary read-only access. Ops managers often need the widest visibility.
The platform had no way to express these nuances. We needed a more flexible, one where each user could have multiple roles, each with fund-specific visibility.
How do you design a system flexible enough to handle multiple roles per user, each scoped to different funds, while keeping it simple, safe, and predictable?
Research
I talked with Fund Admins, Investor Services teams, Fund Counsel, IR teams, and external Auditors to understand how they actually manage access day-to-day and where things break down.
Stakeholder interviews
Fund Administrators
The people actually managing permissions. They're assigning roles, validating access during audits, and handling onboarding and offboarding. They need things to be clear and safe—one mistake can create a compliance issue.
Investor Services & Fund Counsel
People who work across specific funds. They need access to just the funds they support, not everything. Too much access creates noise and makes it harder to focus on their actual work.
IR, Client Services, and Auditors
People who need temporary or limited access. Usually need read-only access for specific engagements. Sensitive to seeing data they shouldn't, and their access needs to align with the scope of their work.
Key Insights
1. Responsibilities vary by fund, not by user.
Teams don't fit into one global role. Their responsibilities shift per fund or vehicle.
2. Admins want clarity, not endless configuration.
They need a simple mental model and clear understanding of what access a user gains.
3. Over-permissioning is a real fear.
Incorrect visibility can expose sensitive investor and fund data.
4. Tenants differ massively in scale.
Some manage 3 funds; others manage 200+. The UX must adapt gracefully.
"I need to give a compliance team member access to just two funds, but the current system is all-or-nothing. So either she sees everything or she can't do her job." — Product
Design Constraints
- Vega handles very sensitive financial information, so access has to be exact.
- Different clients have different fund structures, from a handful to hundreds.
- Every permission change needs to be clearly logged and reviewable.
- Admins need a low-friction, low-stress way to assign access safely.
Design Goals
Based on what I learned, I focused on four core principles:
- Make it flexible. Let users hold multiple roles and scope each role to the right funds.
- Make it simple. Build a mental model that anyone can follow.
- Make it safe. Add previews, warnings, and smart defaults.
- Make it trustworthy. Give compliance teams clear, audit-ready visibility.
Solution
A. Start with the real task: adding a collaborator
I designed the system beginning with the most common action Fund Admins perform — adding a new collaborator. From this point, the workflow needed to feel simple and predictable: choose a role, decide which funds it applies to, and confirm the changes with confidence.
When designing this flow, I focused on three key considerations:
1. Switching between "All funds" and "Selected funds"
Admins wanted to choose "All funds" in one click but still have the flexibility to narrow down if needed. The fund selector had to make this switch effortless.
2. Deep dive: Selecting a fund
When an admin chooses "Select fund," a dropdown opens with the full list of available funds. They can:
- Search by fund name to quickly find specific funds in long lists
- Select individual funds one at a time
- Use "Select all" to quickly choose everything, then deselect exceptions
- See their selections
The dropdown stays open during selection, so you can see your choices build up in real-time. Selected funds appear as removable chips below the dropdown, giving you a clear view of what access you're granting. This makes it easy to catch mistakes before confirming.
For power users managing 100+ funds, the search bar becomes essential. Type a few characters and the list filters instantly. For smaller tenants with 5-10 funds, the full list is scannable at a glance.
The pattern scales gracefully in both directions.
By grounding the design in the actual workflow of adding a collaborator and addressing these specific considerations, I created a system that feels lightweight and intuitive while handling deeply complex permission structures in the background.
3. Each role can be minimized and expanded
Each role is a card that can expand to show full permission details or collapse to show just the essentials—making it easy to scan multiple roles without cognitive overload.
3. Conflict warnings
When role combinations create conflicts or overly broad permissions, the system alerts you before you can apply changes—preventing accidental over-permissioning.
B. Viewing a collaborator's access
When viewing a specific user, admins can see all their roles and which funds each role applies to, giving them a complete picture of that person's access.
Ungrouped view
View all fund assignments in a single list without grouping is useful for quickly scanning the complete set of funds a user can access.
Group by role
To see clearly which roles are assigned to each fund, admins can group the view by roles. This makes it easy to understand the scope of each responsibility.
Results
- Under 4 minutes to configure new user access.
- Reduced permission errors through clear previews and scoping.
- Increased admin confidence through built-in safety controls.
What I Learned
- Enterprise features don't need to feel enterprise. Clarity is king.
- The right mental model can simplify even the most complex logic. When admins understand the hierarchy, configuration becomes intuitive.
- Admin users care deeply about safety. They want to trust the system, which means previews, warnings, and audit trails aren't optional.
- Designing for scale means designing for extremes. The system had to work just as well for 3 funds as it does for 300.