◂ BACK TO CASE STUDIES

Enterprise Permissions

Redesigning how 150K+ T-Mobile employees get access to internal tools, owned end-to-end by content teams instead of IT tickets.

ROLE  Sole designerYEAR  2025SCOPE  150K+ employees
THE PROBLEM
Every permission change was an IT ticket. Content teams waited days for access they should have been able to grant themselves.
THE OUTCOME
A self-serve permission system content teams run on their own: designed, tested, and shipped as the sole designer.
THE CONTEXT

One intranet for 150,000+ employees, permissions owned by content teams.

Three platforms into one intranet for 150K+ employees. Permissions had to ship with launch, owned by content teams, not an IT queue. I was sole designer and one of two business owners across requirements, the group model, both surfaces, a11y, QA, and onboarding.

SCALE
150K+
employees on platform.
MONTH ONE
3,000+
pages permissioned by content teams.
ADMIN LOAD
0
admin interventions needed.
RESEARCH

Grounding the model in how permissions already work, and who would run this one.

Cross-market analysis (SharePoint, Azure, Airtable) plus interviews with admins, content owners, and compliance, then four constraints that shaped the model:

FAMILIAR CONVENTIONS
Admins expect groups, roles, and inheritance language from SharePoint and Azure, but not admin-console complexity.
NEW OPERATORS
Content authors had never managed access. Defaults had to be safe; power had to be gated, not assumed.
SPRAWL IS THE RISK
Legacy had thousands of unowned groups. Ownership and expiration became non‑negotiable in the model, not policy docs.
OPAQUE DATA
HR attributes read like database columns. I inventoried the UXP attribute set and cut/renamed the defaults so authors could build rules without decoding fields.
THE DESIGN BAR
Follow the conventions admins already know. Strip the complexity that assumes a technical operator.
THE GROUP MODEL

Four group types, each with explicit ownership and expiration, so groups can’t sprawl.

Dynamic and exception groups shipped at launch; bulk dynamic and nested groups followed later, by request.

  • Dynamic Launch · default
    Membership from attribute rules, e.g. all People Managers. Updates save immediately, membership syncs overnight.
  • Exception Launch · expiring
    Manual members for contractors and short-lived needs. Must renew to meet cyber policy. Owners get notified as the date nears.
  • Bulk dynamic Later · at scale
    One rule set, many groups: a group for every value of an attribute (e.g. each store, or HR in each state), instead of building them one by one.
  • Nested Later · reuse
    Compose groups and individuals into one audience. Reuse dynamics without rewriting rules.

Four types · one governance contract · launch vs later

Ownership is required at creation, not discovered later in an audit.

Every group names its owners up front. That made accountability visible from day one and gave content teams a clear person to ask when access needed to change.

Set Group Owners: searching and selecting named owners at group creation
Set Group Owners: search, select, and confirm owners before the group exists

Exception groups escalate, then lock, so temporary access cannot quietly stick around.

Renewal prompts appear as the deadline nears. Past the deadline, the group requires review before it can keep granting access.

Exception group card: renew within 30 days warning
Within 30 days: renew before the deadline
Exception group card: past renewal deadline, requires review
Past deadline: review required to restore access
HOW IT WORKS

One loop from group definition to page access, with governance at every step.

Admins define reusable audiences. Authors apply them when content ships. Inheritance and expiration keep the system honest after launch.

01 · DEFINE GROUP MANAGEMENT
Admins create reusable groups
Dynamic rules for steady audiences, exception groups for temporary access. Ownership and expiration are required, not optional.
02 · APPLY APPLY PERMISSIONS
Authors permission pages at publish
Search pages, see publish and permission status, then apply the right groups before go-live, without an IT ticket.
03 · CASCADE EXPLICIT ACTION
Inheritance stays a deliberate choice
Parent access can flow to child pages only when an author confirms it. Visible, reversible, auditable.
04 · GOVERN BUILT-IN EXPIRY
Exceptions renew or expire
Temporary access escalates as the deadline nears, then locks past renewal, so sprawl cannot quietly accumulate.
TWO SURFACES

The same group model, shown where each role needs it.

Admins start in Group Management: find a group, open details, manage membership and rules. Authors work in Apply Permissions at publish time, with publish and permission status side by side before go-live. The hero above is Group Management in motion.

Group Management: group list with New Group menu for Exception, Dynamic, Bulk Dynamic, and Nested
Admins · Group Management: list, search, and create any group type
Apply Permissions: page list with publish status, permission status, and manage actions
Authors · Apply Permissions: publish status and permission status together
DESIGNED FOR FIRST-TIME OWNERS

Familiar patterns, safer defaults, and errors caught at the moment of entry.

The platform had no established patterns for search, tables, filtering, or inline validation. I designed them to align with the new design system’s semantic tokens and interaction patterns. Purpose-built for Permissions, reviewed with the DS team and a11y partner, and signed off before ship.

Foundations first
Search, tables, filters, and validation shipped as shared components within Permissions, not generic library widgets reused from elsewhere. Bulk imports flag bad rows inline and skip them, so good entries still proceed.
Search Data table Filters Validation
Group Management filtered to Dynamic: search, group type and owner filters, and results table
Management view: search, filters, and table: the same patterns owners use day to day
Create Exception Group: member search, bulk import, toast for invalid rows, and per-row inline validation
Create Exception Group: bulk import keeps valid members and flags bad rows inline

A rule builder for two audiences: visual for most, syntax for the advanced.

I renamed cryptic HR attributes for non-technical authors and cut the default list by more than half. The live syntax view validates complex logic as it’s built.

People_manager_flag People Manager
Leader_2 Employee Level
Wrk_loc_cd Work Location
Create Dynamic Group: visual rule builder with live rule syntax view
Create Dynamic Group: visual expressions with a live syntax preview
KEY DECISION
INHERITANCE AT MIGRATION SCALE
Inheritance is an explicit author action, never a silent cascade.

Automatic inheritance wasn’t technically feasible at migration scale, and most alternatives were too complex to build or too opaque for authors. Instead, authors choose when parent access flows to child pages, with clear control over which groups apply. Visible, reversible, auditable. A later enhancement let pages inherit from already-permissioned parents, cutting effort further.

Apply Permissions: explicit add-parent and replace-child inheritance actions with confirmation
Update child pages: add parent groups, or replace child groups, each with a confirmation
Open unless compliance says otherwise
Content is open by default and locked down only where compliance requires it, so most of the intranet stays usable without maintaining permissions on every page.
IMPACT
3,000+
pages permissioned in month one · zero admin intervention
~30
governed groups at steady state
0
IT tickets for routine access changes

Model held months after launch. I did deep manual validation against real HR data (SQL, Postman, cron behavior) before builds were finished. That work surfaced overnight sync, mismatched attribute labels, and other gaps the spec never mentioned. I wrote the admin/author guides and a failsafe BRD, and onboarded content teams before platform go live.

  1. 01
    Governance works when it’s built into the model, not a policy doc.
  2. 02
    Design for the least-technical owner. Safer for everyone, including admins.
  3. 03
    The constraints that mattered most (overnight sync, opaque HR attributes, UI terms that didn’t match the system) I found by testing, not by spec.
NEXT CASE STUDY · NO.2
MyIntake: a health profile any clinic can scan
OPEN →