Permission-Aware Page Flow
A single page that adapts its behavior based on the current user's role — admin, member, or guest.
Problem this solves
Most admin pages assume full access. In reality, different users have different permissions. This flow shows how to render the same page differently based on role: full control for admins, read-only for members, and a blocked state for guests — with clear feedback at every level.
Use this pattern for any page with role-based access: team management, billing settings, API key management, audit logs. The key decision is whether to hide restricted UI entirely or show it as disabled with an explanation.
Interactive demo
Switch roles to see how the page adapts.
Team members
Manage your team and their permissions.
| Member | Role | Joined | Actions |
|---|---|---|---|
Alice Johnson alice@example.com | Owner | Jan 2024 | |
Bob Smith bob@example.com | Admin | Mar 2024 | |
Carol White carol@example.com | Member | Jun 2024 | |
Dan Brown dan@example.com | Member | Sep 2024 |
Decision logic
| Role | View data | Edit / Delete | Invite | UI approach |
|---|---|---|---|---|
| Admin | Yes | Yes | Yes | Full interactive page |
| Member | Yes | Disabled | Disabled | Read-only with banner + disabled buttons |
| Guest | No | No | No | Blocked state with access request |
Disabled vs Hidden
This flow uses disabled buttons for members instead of hiding them. This is intentional — users should understand what actions exist and why they can't perform them. Hiding UI creates confusion ("where did the delete button go?"). Disabling with a tooltip explains the restriction. Only block the entire page when the user has no meaningful access at all (guest role).