Permission hierarchy diagram
Roles, permissions, and inheritance for access control systems.
Every application has users with different capabilities: some can create content, some can only read, some can delete. Managing these permissions without a clear model leads to security holes (users with too much access) and frustration (users with too little). This template shows how to structure roles and permissions so you can grant the right access to the right users at scale.
The class diagram makes inheritance clear: an Admin role extends the base Role, gaining all Admin-specific permissions on top of shared ones. A Moderator role extends Role with different permissions. Users are assigned to roles, not individual permissions, which keeps access control simple even as your system grows.
When to use this template
- Designing access control — before you code authentication, sketch the role hierarchy. This forces you to name roles and permissions explicitly, reducing confusion later.
- Compliance and audit — regulatory reviews need to see who can do what. This diagram is the single source of truth for access policies.
- Onboarding new team members — instead of explaining "managers can see reports but not delete data", show them the role hierarchy. The structure makes rules obvious.
How to adapt it
Start by listing your real roles and the permissions they need:
- Custom roles — replace Viewer/Moderator/Admin with your roles: Customer, Agent, Manager, Finance, Compliance.
- Permission grouping — break down specific permissions: create-post, edit-post, delete-post (granular) or content-management (grouped).
- Add attributes — give users an
organizationorteamfield, and roles adefault_assigneescount, to show which roles are rare vs. common.
Visual edits regenerate clean code, so you can add roles and rearrange inheritance without writing class syntax.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
classDiagram
class Permission
class Role
class User
class Admin
class Moderator
class Viewer
Permission: +create
Permission: +read
Permission: +update
Permission: +delete
Role: +name
Role: +permissions[]
User: +id
User: +email
User: +roles[]
Admin --|> Role : extends
Moderator --|> Role : extends
Viewer --|> Role : extends
Role "*" --> "*" Permission : has
User "*" --> "*" Role : assigned
Frequently asked questions
- What is a permission hierarchy class diagram?
- It shows how roles relate to each other (Admin extends Role, Moderator extends Role, Viewer extends Role), which permissions belong to which roles, and how users get assigned roles. This structure is the foundation of access control: instead of giving each user individual permissions, you assign them a role that bundles related permissions.
- Why use a class diagram instead of a flowchart for permissions?
- Class diagrams show inheritance (Admin extends Role, gaining all base role capabilities) and relationships (a Role has many Permissions). This makes visible the permission reuse and delegation that flowcharts hide. Architects need to see the structure to reason about scaling access control to thousands of users and roles.
- What is the difference between a role and a permission?
- A permission is a single capability: 'create content', 'delete user', 'export data'. A role is a bundle of permissions: an Admin role includes create, read, update, delete; a Viewer role only has read. Users are assigned roles, not individual permissions, so revoking a permission means updating one role instead of every affected user.
- How do I adapt this for my product?
- Replace Admin/Moderator/Viewer with your actual roles (Customer, Support Agent, Manager, Executive). Add specific permissions your product needs (publish, audit, refund). Use the visual editor to add new role classes and draw relationships — no syntax required. Visual edits regenerate clean code.
Related templates
Multi-tenant architecture
Database isolation patterns for SaaS: shared schema, separate databases, and hybrid.
API rate limiting sequence
Client, gateway, and limiter handling a 429 with Retry-After.
Network topology diagram
Internet, regions, load balancers, subnets, and security boundaries.