1. Introduction
Dash.fi serves high-growth companies with massive advertising budgets. As these teams scale, the primary account holder (usually a CEO or CFO) face a significant challenge: how to delegate spending power without sacrificing financial security. I led the design and implementation of a robust User Roles and Permissions framework to transition Dash.fi from a single-user tool into an enterprise-ready financial ecosystem.
2. The Problem
As Dash.fi moved up-market, our users changed from individual entrepreneurs to CFOs of multi-entity holding companies. These users faced a "Visibility vs. Control" crisis. They needed to manage ad spend across different legal entities (e.g., a parent agency and its sub-brands) without sharing a single login or exposing sensitive data across departments. The existing system lacked the granularity to handle diverse user needs, leading to security risks and operational bottlenecks.
3. Research & Structural Mapping
Through stakeholder interviews and competitive audits, I mapped the "Power User" journey. We identified that a "One-Size-Fits-All" role was the primary reason for a 40% friction rate in team onboarding. We needed a system that reflected real-world corporate structures.I defined four primary personas to anchor our Role-Based Access Control (RBAC):Admin/Owner: Full legal accountability; manages high-level credit lines and entity-wide settings.Finance: Focused on reconciliation; has high visibility into transactions across entities but limited card-issuing power.Card Manager: Mid-level oversight; authorized to create and assign cards to specific teams or projects.Employee: The end-user; restricted to their own card details, balance requests, and receipt uploads.
4. Design Strategy: The Multi-Entity Architecture
The breakthrough in this project was the Multi-Entity Switcher. I designed a global navigation layer that allowed "Super-Admins" and "Finance" roles to toggle between different business entities without logging out.
Cross-Entity Permissions: I developed a logic where a user could be a "Finance" role for Entity A, but only an "Employee" for Entity B.
The "Least Privilege" Principle: I implemented a default-restrictive UI. If an Employee logs in, the "Create Card" and "Company Settings" buttons are programmatically hidden, reducing cognitive load and preventing unauthorized actions.
Smart Invitations: I redesigned the invite flow to allow Admins to assign roles and specific entity access before the invitation is sent, ensuring that new hires land in a pre-configured, secure environment.
