Permission & Role States
What the UI looks like when the user can see things but can't touch them — or can't see them at all.
No access — full page block
The user navigated to a section they have zero access to. Not a 404 — they know the page exists, they just can't use it. This is different from a permission error on a single action.
You don't have access to Billing
This section is restricted to the Owner and Admin roles. Contact your workspace owner to request access.
Show when a user's role has no access to an entire section (e.g., a Viewer trying to access Billing). Always name the required role and tell them who to ask.
Partial access — visible but disabled
The user can see the settings page but can only change some fields. Other fields are locked because they require a higher role. This is extremely common in multi-tenant B2B apps where Editors can change content but not billing or security settings.
Workspace settings
You can edit general settings. Security settings require Admin access.
General
Security
Requires Admin roleShow the full page but disable specific sections with a clear explanation of why. Never hide the section entirely — partial visibility helps users understand the product's capabilities and motivates role upgrades.
Read-only viewer — table with hidden actions
A Viewer can see the team members list but can't invite, edit, or remove anyone. The action buttons should either be hidden or visibly disabled. Hiding is cleaner; disabling is more transparent.
Team members
4 members
| Name | Role | Status |
|---|---|---|
| Alice Johnson | Owner | Active |
| Bob Smith | Admin | Active |
| Carol White | Editor | Active |
| You | Viewer | Active |
You have view-only access. Contact an Admin to manage team members.
Show on any data page where the user's role is read-only. The approach here hides destructive actions entirely and shows a subtle role indicator. This is the cleaner pattern for Viewer roles.
Role-based UI differences
The same page looks different depending on the user's role. Admins see all actions, Editors see edit but not delete, Viewers see read-only. Showing these side-by-side helps developers understand what to conditionally render.
Same project row, three different roles:
Project Alpha
Full access: settings, edit, delete
Project Alpha
Can edit content, no delete or settings
Project Alpha
Read onlyCan view, no actions available
Use this as a reference when implementing role-based conditional rendering. Map out which UI elements each role sees before writing code. This prevents accidental permission leaks.
Disabled action with inline explanation
A specific button is disabled because the user's role doesn't allow it. Instead of just graying it out, explain why directly next to the button. This is better UX than a tooltip because it's always visible.
API Keys
Manage API keys for this workspace.
Production
sk_live_...a8f2
Staging
sk_test_...c3d1
Use when a single action is disabled due to permissions but the rest of the page is functional. Always explain the reason inline — don't make users hover to find out why something is grayed out.