PORT: Permissions, Orgs, Roles and Teams

Command settings showing the Team Management roster, with a Manage Permissions modal open over it. Each app is listed down the left with its permission level, against Standard, Enhanced and Unlimited columns.

In 2023, a data breach revealed a critical vulnerability in our platform: widespread credential sharing among our Solo (non-Team) user base. Because the platform lacked collaborative tools for Solo agents, they were sharing usernames and passwords to grant access to their assistants.

Command was originally built for individual use. A 2021 effort to support teams had been under-scoped, resulting in a fragmented architecture where users were trapped in split Solo/Team contexts. For years, the UX team tracked these pain points, but the complex migration work was repeatedly deprioritized. The 2023 breach made it so the issue was no longer a UX pain point — it was a security mandate.

Within months, this evolved into “PORT” (Permissions, Orgs, Roles, Teams), a prioritized initiative spanning 10+ product teams. As UX Lead, I was responsible for the strategic migration of 178,000 users to a multi-tenant model that balanced urgent security requirements with complex cross-platform dependencies.

Strategic trade-offs: migration vs. innovation

Our core dilemma was how to provide Solo agents with collaborative access without creating more security risks. We evaluated two paths: building guest functionality into existing Solo accounts (a low-effort, short-term fix) or migrating Solo accounts to the Team architecture (a high-effort, long-term structural solution).

We selected the latter. We positioned the migration not just as a security patch, but as a strategic unlock for revenue-driving initiatives like expansion teams, per-seat licensing, and white-label partnerships. I worked with a “Tiger Team” of engineering leads to prove a multi-tenant architecture could solve the UX debt while securing the platform. Following a successful POC, we negotiated a phased roadmap to deliver the 18-month project.

Proof-of-concept designs for a Command that shows a user everything across all of their teams at once. — As part of the POC, I created designs showing a future vision of Command that allowed users to see across all of their Teams.

Designing the migration: triaging friction

Priority #1 was migrating 178,000 active Solo accounts to the Team experience. The challenge was preventing “feature shock” — forcing a Team-centric UX onto users who didn’t actually have teammates.

I audited every flow for severity. Anything a Solo user couldn’t answer was flagged as a blocker. Lower-risk items (copy variants, optional fields) were validated with current users and treated as standard CRM expectations.

Adaptive Lead Routing: Rather than forcing Team-level routing logic on Solo agents, I redesigned the flow to read roster counts and user preferences, conditionally surfacing routing steps only when they added value.

Secure Onboarding: The original flow relied on Team Admins setting passwords for guests — a new vector for credential sharing. I designed a flow that empowered guests to own their credentials, facilitating secure, multi-team access for those who supported multiple agent teams.

Infrastructure Alerting: I discovered a communication gap between agents and Market Center (MC) staff — neither side received notifications for invitation approvals. I escalated this as a critical UI failure and designed a notification system that integrated toast alerts and a centralized dashboard for MC staff.

Requirements documentation for the Team Management experience, specifying states and behaviour for the build teams.

Governance: scaling through documentation

The center of PORT was the Team Management page, a modal-based editor with per-app tabs and a permission grid. The challenge wasn’t just the UI; it was ensuring 10+ independent product teams shipped consistent patterns against it.

I shifted my role from “screen designer” to “UX advisor.” I embedded with teams during kickoff, published documentation, and maintained a regular design review cadence. Two frameworks were essential to this alignment:

The Disabled-vs-Hidden Framework: I authored a rule set to eliminate inconsistency in how teams handled restricted actions. (e.g., Hide if the user is unauthorized; Show as disabled/explained if the action is state-dependent.)

Permission Copywriting Guidelines: To fix the fragmented language across apps (e.g., “Edit Contacts” vs. “Update contact info”), I created a standard grammar pattern for permission screens, ensuring consistent verb usage across the platform.

These documents didn’t just align the teams — they were eventually ingested into the company’s internal AI tooling, codifying my design governance for future teams.

The design governance documentation published for the ten-plus product teams building against PORT.

Lessons in alignment: CommandMC

Alignment faltered during the CommandMC integration. The CommandMC team, operating with different priorities, introduced “feature groups” to granularize permissions, creating a disconnect between the two platforms.

CommandMC's permissions modal. Each applet expands into feature sub-groups such as Recruiting Pipeline and Recruit Details, each carrying its own No Access, Standard, Enhanced and Unlimited setting on top of the individual permissions nested beneath. — **Current** — CommandMC's sub-groups added more control, but more complexity.

A proposed CommandMC permissions modal that drops the feature sub-groups and matches Command's flatter structure. — **Proposed** — a fallback that aligns with Command's implementation.

Beta testing revealed the mismatch: feature groups added cognitive load without functional benefit, disorienting users who moved between the Command and CommandMC environments. While I advocated for a rollback to platform-wide alignment, the product teams were anchored to their build.

I left the company before the final decision, but the experience highlighted a critical lesson: cross-platform dependencies must be flagged as structural risks at the start of the build, not during Beta testing. In retrospect, I would have escalated the structural inconsistency to executive leadership the moment it appeared, rather than attempting to solve it as a cleanup task.

Outcomes

PORT successfully unified the platform ecosystem:

Every application migrated to the Team model and supported custom permissions
Solo agents gained a secure, legitimate path for assistant collaboration
The architecture removed the long-standing blocker for revenue initiatives and simplified the user journey by eliminating the “Team vs. Solo” context-switching

Feedback from our user advocate panels confirmed the value: Solo agents appreciated the professional collaborative tools, and Team users finally experienced a unified platform. The project was recognized as a top-tier cross-team initiative, and the governance frameworks I established remain the operational standard for platform design at the company.