Enterprise Permissions
Enabling content teams to manage access for 100,000+ employees across a unified platform.
2025
Year
6 Months
Duration
T-Mobile
Company
System Design & UI
Category
The administrative surfaces for managing permissions across enterprise content.
The Problem
T-Mobile consolidated multiple internal platforms into a single experience for over 150,000 employees and third-party groups. Permissions were fragmented across those systems, dependent on technical SMEs with thousands of groups near-impossible to audit consistently at scale.
As part of the consolidation, access management became a shared responsibility across content teams that needed to meet compliance and audience needs often defined by role, location, or employment type. With no out-of-the-box solution, a system needed to be designed and built from the ground up.
My Role & Ownership
I was the sole product designer and one of the primary business owners for the enterprise permissions system.
Product Definition & Design
Led requirements sessions, mapped authoring needs to product features, and iterated through explorations and stakeholder reviews to MVP launch.
Cross-Functional Execution
Led a dedicated business workstream and partnered with product, accessibility, and design systems teams to meet user needs, technical constraints, and A11y standards.
Governance & Adoption
Established group governance standards, led QA and BVT testing, and supported content team onboarding through documentation and training at launch.
Solution Overview
A centralized permissions system built around reusable employee groups, giving content teams direct control over access as part of their everyday workflows. At launch, the system was adopted across multiple organizational groups with over 3,000 pages permissioned in the first month, maintained through a streamlined set of around 30 active groups.
Group Management - for key content managers and admins to create and maintain employee groups for reuse across the platform.
Apply Permissions - for content authors to control which groups could view pages and components during everyday authoring workflows.
Defining the Group Model
The system supported four group types: dynamic groups, exception groups, bulk groups, and nested groups.
Dynamic and exception groups formed the core of the model. Dynamic groups were the default, while exception groups were reserved for cases that couldn’t be expressed through logic, such as testing, contractors, or short-lived projects. Bulk and nested groups supported speed and reuse without changing or duplicating core group definitions.
To define the group model I analyzed enterprise permission systems including SharePoint, Azure, and Airtable, and interviewed teams who regularly managed access. The goal was a model that followed familiar permission conventions but was approachable for content authors who had never managed access before.
Dynamic Groups
Dynamic groups were most commonly used for access groups, updating daily based on employee attributes and defined membership logic without manual upkeep.
I designed a rule builder with a visual UI for most use cases and a live syntax view for advanced users to validate and troubleshoot complex rules.
The rule builder supported visual composition for most users alongside a live syntax view for advanced users to validate and troubleshoot complex logic.
Attribute names were revised for non-technical users and the default attribute list was reduced by over 50% from the original technical set to keep rule creation simpler and safer at scale
Group Management
Each group had a dedicated management view showing rule logic, membership, applied content, and activity history. Giving administrators visibility into downstream impact and supporting audit capabilities.
Group management provides a snapshot of rule logic, membership, applied content, and change history, each expandable for more detail.
Exception Groups
Exception groups supported access needs that couldn't be expressed through logic, such as short-term access, external partners, or testing scenarios. Bulk import and manual management made them practical to maintain at scale.
Explicit ownership and expiration requirements directly addressed a recurring problem in prior systems, where thousands of unused manual groups had accumulated with no clear ownership or process for removal.
Manual exception group creation with bulk import, flagging failed entries.
Warning and overdue states prompting group owners to review and renew temporary access before it becomes untracked.
Applying Permissions at Scale
Once groups were defined, the next challenge was enabling content teams to apply permissions safely across a large and growing set of pages and components, a responsibility new to most authors working alongside multiple teams managing different content in the same environment.
Apply Permissions was designed to mirror the interaction patterns of Group Management, reducing complexity for users working across both tools and limiting technical build debt. The design prioritized visibility into pages and changes before they were applied, addressing the lack of visibility into permission status across pages that had made access management difficult to track and audit in prior systems.
The central authoring hub where content teams searched pages and tracked publish and permissions status across the platform.
Underlying Behavior
Rather than restricting access by default, the system was designed to be open unless compliance required otherwise, reducing ongoing maintenance across a large content set and keeping enterprise resources broadly accessible.
Automatic inheritance for nested content was not technically feasible despite being a critical requirement for the migration scale. After exploring multiple approaches with engineering and stakeholders, with many too complex to build or difficult for authors to understand, inheritance was designed as an explicit cascading action.
Authors could apply parent permissions to child pages with clear control over which groups were applied, making the impact visible and reversible. A later enhancement enabled inheritance from already-permissioned parent pages to further reduce effort.
Permission inheritance was designed as an explicit action, giving authors control over how and when parent access applied to child content.
Component Permissions
Component permissions followed the same flow as pages, exposed through an additional tab within Apply Permissions. This preserved the existing author mental model while reducing build complexity.
Global components like navigation and search responded inherently to page-level access rules, ensuring users only saw entry points they were authorized to access without additional configuration.
Component inherits page-level permissions until edited, and apply only to each specific component.
Governance & Adoption
The permissions system launched on time and was quickly adopted across multiple organizational groups. Over 3,000 pages were migrated and permissioned within the first month, with content teams managing access independently and without platform admin intervention.
As adoption grew, additional safeguards were added to support safe change at scale. Group ownership was made explicit, change logs provided more visibility into updates, and large dynamic group updates triggered warnings when they exceeded set thresholds. These safeguards prioritized trust, recoverability, and operational confidence without slowing everyday authoring workflows.
The core group model, inheritance rules, and governance structure remained intact months after launch demonstrating that decisions around defaults, explicitness, and guardrails supported real operational needs over time.