Permission Toggle
Tool
A switch that opens or closes a feature based on plan tier or account role, and unlike other flags it stays in the product for good.
Why it exists
The moment pricing had tiers, the same product had to look different to different customers. That distinction first went straight into the code — a condition comparing the tier next to every paid feature, or a separate screen per tier. Then any change to the plan lineup dragged a deploy along with it.
Pagedeck ran into that wall. Audit logs were meant for the team plan only, and Sofia got a request from a prospect who wanted to see the feature before signing. With the condition baked into the code, there was no way to open it for that one account. Theo spent two days writing an exception and shipping it.
What it solves
It pulls the condition for opening a feature out of the code, so it can be changed per account without a deploy. It's one of three uses for a feature flag, the mechanism that keeps a feature deployed while a switch decides whether it runs.
This switch carries three jobs.
- Tying features to plans. In tiered pricing, where features are bundled into levels, which level gets what becomes configuration rather than code. Rework the plans and the code stays as it is.
- Exceptions for a single account. Opening one feature early for a prospect, or opening it for a fixed trial period. It gives sales something to offer in the room.
- Role-based visibility. Even inside one company, some screens belong to administrators only — member invitations and billing details being the usual ones.
What separates it from the other two toggles is lifespan. A switch that hides unfinished work or splits users for comparison gets stripped out of the code once the job ends. A permission toggle stays as long as the pricing does, so no removal date gets attached to it. What it needs instead is one place that shows which tier has what.
Hiding a button on screen isn't the same as blocking it. Typing the address directly often opens the page anyway, so the same condition has to be checked on the server as well as in the interface.
How it sounds at work
"Turn on audit logs for just that account. The permission toggle can open it."
A request to open a feature for one account without a deploy.
"That's a permission toggle, not a release toggle — take it off the cleanup list."
It isn't temporary; it's meant to stay.
"It's hidden in the UI but the server isn't checking."
The permission is enforced on one side only, so it can be worked around.
Theo now records the kind of switch when he adds one. Temporary ones get a removal date; permission toggles get a note about which tier and role the condition covers. Sofia can offer early access to a feature during a negotiation and mean it.
Easily confused with
| Term | What it divides | How it differs |
|---|---|---|
| Release toggle | Finished or not | Hides work that isn't ready to show. It comes out of the code once everyone has it |
| Experiment toggle | Groups to compare | Splits users to measure which version does better. When the test ends, the winner stays and the switch goes |
Where to go next
- Feature flag
see how all three uses sit on one mechanism
- Release toggle
the lifespan and cleanup of the temporary case
Last updated 2026-09-16