The Permission System That Made Everyone an Admin (By Accident)
The Quest for Perfect Permissions
Our client ran a complex digital publication with a labyrinthine editorial hierarchy. Managing editors, section editors, staff writers, freelance contributors, fact-checkers, copy editors, social media managers, and interns—all with different access needs and responsibilities.
Twill's built-in user roles felt too basic for their operation. "We need granular control," the editorial director explained. "Sarah should be able to edit tech articles but only publish lifestyle pieces. Mark can manage media but shouldn't access user data. Interns should see drafts but not financial reports."
I was excited by the challenge. Instead of Twill's standard role-based system, we'd build something sophisticated—a fine-grained permission matrix that could handle any conceivable combination of access needs.
The system I designed was genuinely elegant:
Resource-based permissions: Separate controls for articles, media, users, settings, analytics
Action-based granularity: Create, read, update, delete, publish, feature, archive permissions for each resource
Conditional permissions: Time-based access, content-category restrictions, approval workflows
Permission inheritance: Role hierarchies with override capabilities
Dynamic rule engine: Custom permission logic based on user attributes, content metadata, and editorial calendar
During the demo, I walked through dozens of permission scenarios. "Watch this," I said proudly, "Sarah gets 'tech-writer' role, which grants her edit access to technology category posts, but only during business hours, and only for posts she created or that are assigned to her team."
The client was impressed. "This is exactly what we needed. Finally, a permission system that matches how we actually work."
The Configuration Nightmare
Three months after launch, I got a panicked call from the editorial director.
"I think we have a security problem," she said. "Jenny, our new social media intern, somehow published a draft article that wasn't supposed to go live until next week. And she was able to delete media files that she definitely shouldn't have access to."
I logged into the admin panel to investigate. What I found was a permission configuration that looked like someone had thrown a handful of checkboxes at a wall and deployed whatever stuck.
Jenny's user profile showed:
Base role: "Social Media Intern"
Override permissions: "Can edit featured content" (granted because she needed to update social previews)
Inherited permissions: "Content Manager" (assigned accidentally during a bulk user import)
Time-based access: "Publishing rights during social media posting hours" (which happened to be 9 AM - 11 PM)
Category overrides: "Can manage lifestyle content" (because she helped with Instagram posts)
The permission system had resolved this complex rule set into: effectively full admin access.
When Flexibility Meets Reality
The more I investigated, the more horrifying the situation became. Our beautiful, granular permission system had become a permission explosion.
We had 47 different permission types across 12 resource categories with 8 action levels each. A single user could have permissions granted through:
Their base role assignment
Direct permission grants
Group membership inheritance
Time-based conditional access
Category-specific overrides
Workflow-based temporary elevations
Emergency access provisions
Nobody—including me—could look at a user's permission profile and quickly understand what they could actually do.
The Sarah Problem: Remember Sarah, our tech writer with carefully crafted conditional access? Her permission profile had evolved over six months of "quick fixes" and "temporary grants" into an incomprehensible matrix. She now had:
Tech article editing (original requirement)
Lifestyle article publishing (added for a special project)
Media library full access (granted during a photo shoot)
User management rights (accidentally inherited from a group)
Analytics dashboard access (added for a reporting deadline)
Emergency publishing override (granted during a weekend crisis)
Sarah had become a de facto admin without anyone realizing it, including Sarah herself.
The Escalation Cascade
The real security nightmare wasn't what people could do—it was what they didn't know they could do.
During a routine content audit, we discovered:
The intern who could delete entire article categories (through a combination of media access + workflow overrides + inherited group permissions)
The freelance writer who had access to subscriber analytics (time-based access grant that never expired + category permission overlap)
The copy editor who could create new user accounts (inherited from a temporary "content manager" group assignment during a staff shortage)
None of these users knew they had these permissions. They were all following their understood role boundaries, but our system had quietly granted them much broader access through the complex interaction of permission rules.
The Permission Debugging Hell
When the editorial director asked me to audit everyone's access, I realized we'd created a permission system that was fundamentally unauditable.
To understand what any single user could actually do, I had to:
Check their base role permissions
Review all direct permission grants
Evaluate group membership inheritance chains
Calculate time-based conditional access windows
Process category-specific overrides and exceptions
Factor in workflow-based temporary elevations
Account for emergency access provisions
Resolve conflicts between competing permission rules
For a single user, this process took me nearly an hour. We had 23 active users.
Worse, the permission resolution logic was so complex that I'd introduced several bugs in the rule evaluation engine. There were edge cases where permissions were granted that shouldn't exist, and other cases where legitimate access was accidentally blocked.
The Friday Afternoon Bug: We discovered that users who joined the system on Fridays inherited different permissions than users who joined on other days, due to a timezone calculation error in the conditional access logic. This had been happening for months without anyone noticing.
The Security Theater Revelation
The most embarrassing realization was that our "secure" system was actually less secure than Twill's simple role-based approach.
With basic roles, security is obvious:
Admins can do admin things
Editors can edit and publish
Writers can write and suggest
Viewers can view
Everyone understands their boundaries. Violations are immediately obvious. Auditing access takes minutes, not hours.
Our granular system had created security through obscurity—not obscurity from attackers, but obscurity from ourselves. We couldn't quickly verify who had access to what, which meant we couldn't quickly identify when something was wrong.
The Breaking Point
The system collapsed during a routine staff reorganization.
When the editorial director tried to move three writers from the "Lifestyle" team to the "Technology" team, she had to navigate through dozens of permission changes across multiple categories. The process that should have taken five minutes required two hours and three different admin users to complete.
But the real disaster was what we missed: the permission changes accidentally granted one of the moved writers access to unpublished financial reports. We didn't discover this until a confidential revenue document showed up in the preview queue for social media posting.
The editorial director's feedback was swift and clear: "This system is too complex to manage safely. We need something we can understand."
The Humbling Rebuild
We redesigned around role simplicity:
Four primary roles: Admin, Editor, Writer, Contributor
Clear permission boundaries with no inheritance overlap
Temporary access grants that expired automatically after 48 hours
Single-purpose overrides that could only add specific, named permissions
Permission audit trail showing exactly what changed and when
Plain English permission summaries for each user
The new system handled 95% of their use cases with roles alone. The remaining 5% were handled through temporary, explicit permission grants that automatically expired.
What We Actually Learned
1. Complexity Is a Security Vulnerability
The more complex your permission system, the more likely you are to accidentally grant access you didn't intend. Simple systems have obvious security boundaries.
2. Auditability Is a Feature
If you can't quickly verify who has access to what, your permission system is broken. Security you can't audit isn't security.
3. Edge Cases Aren't Worth the Edge
Handling 100% of permission edge cases isn't worth making the 95% common cases incomprehensible. Sometimes "close enough" is better than "perfectly granular."
4. Users Need to Understand Their Own Permissions
If users don't know what they're allowed to do, they'll either do too little (out of caution) or too much (out of ignorance). Both are problems.
The Real Permission System
The best permission system isn't the one that can handle every possible scenario. It's the one that makes the right access obvious and the wrong access impossible.
Our final approach wasn't technically impressive, but it was human-comprehensible. Every user could explain their own permissions in a single sentence. Every admin could audit access in minutes, not hours.
Sometimes the most secure system is the one that trades flexibility for clarity.
Have you built permission systems that became too clever for their own good? Security through complexity is still security through obscurity—share your stories of permission systems that became permission problems.
Made with Twill | twillcms.com