Users & Roles
Simplifying a permission system that had grown beyond anyone's ability to predict what a user could actually do.
Users list with the new role model: clear Role column, scoped permissions, and organization hierarchy.
Before
Add User modal with a scrollable list of role toggles. 16 roles with descriptions that don't explain overlap. Admins toggled multiple roles defensively because they couldn't tell what was already included.
After
Redesigned user invitation with role as a single dropdown (default: Community Manager), expandable permissions, and scoped access per Network/Division.
The New Model
16 roles became 4. Each role maps to a clear organizational scope with no overlap. Optional permissions extend capabilities without adding role complexity.
Organization Administrator
Full access across the entire organization
Platform configuration and governance. Access to all operational areas. No additional roles needed.
Division Administrator
Full access within a specific division
Division-level configuration and governance. Same access scope as Org Admin, but contained to one division.
Community Manager
Day-to-day operations without platform settings
Works with creators, campaigns, lists, and reports. Default role for all new users. Can be extended with Payments and Extended Management permissions.
Community Coordinator
Creator-focused work only
Discovers, adds, and communicates with creators. Organizes into lists. No access to campaigns, reporting, or settings.
Permissions as extensions, not roles
Instead of creating more roles for edge cases, we separated optional capabilities into permissions that extend any role. A user has one role and zero or more permissions.
Payments Permissions
Three tiers: View, Edit, and Full access. Included by default for Manager and Admin roles. Cannot be assigned to Community Coordinator.
Extended Management
Grants full CRUD on objects owned by other users. Available to Community Manager and Community Coordinator roles.
Key Design Decisions
Community Manager as the default
We debated whether the default role should be the most restrictive (Community Coordinator) or the most common (Community Manager). Security logic says default to least privilege. But 80%+ of new users needed campaign and list access on day one. Defaulting to Coordinator would mean every onboarding required a follow-up permission change. Community Manager gives the right access out of the box for most users.
The safest default is the one that doesn't generate workarounds. A restrictive default that everyone overrides is more dangerous than a practical default that occasionally needs narrowing.
Backend-ready for multi-role, UI stays single-role
The data model supports assigning multiple roles per user, but the UI only exposes single-role assignment. We could have shipped multi-role from day one, but that reintroduces the combinatorial complexity we were trying to eliminate. The four-role model is designed so one role per user is enough. Multi-role stays available as a future escape hatch.
Designing the backend for flexibility while keeping the UI constrained. The best permission system is one where users rarely need to think about permissions.
Context
CreatorIQ had 16 roles spread across six product areas. Each area added its own roles independently. Roles silently included other roles, but this overlap was invisible in the UI. Admins stacked roles defensively because they couldn't tell what was already included.
16 roles across 6 areas
Talent
Talent Search, Talent Manager, Talent Administrator
Campaigns
Campaign Search, Campaign Manager, Campaign Administrator
Lists
List Manager
Payments
Payments Manager
Discovery
Discovery Manager
Administration
System Administrator, Network Administrator, Division Administrator
The real cost was unpredictable access. After stacking multiple overlapping roles on a user, it became impossible to understand what that user could actually do. The enablement team felt this most during onboarding — every bulk import required manual role selection per user from a list of 16 options.
Note
This project is currently in Solution Shaping. The role model, permission structure, and assignment logic are designed and documented. Implementation is planned for Q2 2026.
Want to discuss the details?
The role model, permission matrix, and assignment flows are better walked through than read. Let's talk.
Book a call