Permission & Access Control
Permission screens are where trust gets designed — who can see what, who can invite whom, what happens when access is denied. We mapped 152 permission instances across Notion, Slack, Figma, Linear, GitHub, Atlassian, Asana, Airtable, Dropbox, and Trello, covering invite flows, role models, share dialogs, access-denied pages, and destructive actions. The data shows strong consensus in some areas ("Invite" dominates member lists in 8 of 10 systems) but wide divergence in others — role complexity ranges from 2 tiers to 8, and half the systems have no request-access flow at all.
Member Management
8 of 10 systems use 'Invite' as the primary CTA on member lists
"Invite" is the consensus verb for adding people to a workspace, used by Figma, Slack, GitHub, Airtable, Atlassian, Asana, Linear, and Trello. Only Notion uses "Add members" instead. The distinction matters: "invite" implies the person has agency to accept or decline, while "add" implies the admin is placing them directly.
Use "Invite" as your primary CTA on member lists. The framing signals that the person being added has agency over whether to join.
Member Management
9 of 10 systems segment their member list with tabs or sidebar sections
Almost every system separates its member list into meaningful segments. GitHub has the deepest segmentation with 6 sidebar sections including a dedicated "Failed invitations" section for debugging delivery issues. Asana is the only system with a "Removed" tab, keeping a record of deprovisioned users. Airtable separates "Collaborators" from "Pending invites" at the workspace level. For compliance, 4 of 10 systems offer CSV export: Slack, GitHub, Airtable, and Linear. Asana adds CSV import for bulk onboarding.
Segment your member list with tabs or sidebar sections. At minimum, separate active members from pending invites. Add CSV export for compliance and a "Removed" tab if your product needs audit trails.
Member Management
3 of 10 systems show seat limits directly on the member list
Airtable shows "5 editors, 50 commenters" with usage bars on its collaborator settings page. Asana displays "1 of 2 members invited. Upgrade to add more members." Trello shows a "1/10" collaborator count with an upgrade prompt. The remaining 7 systems hide seat limits from the member list entirely, surfacing them only in billing settings.
Show seat limits on the member list if your product has plan-gated capacity. Displaying the count next to the invite CTA prevents failed invites and creates a natural upgrade prompt.
Member Management
How pending invites appear splits evenly between inline and separate tabs
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Role Models
Role tiers range from 2 (Linear) to 8 (Asana) with a median of 6
The simplest permission model is Linear's 2-tier system (Admin and Member), while Asana has the most complex at 8 tiers spanning org and resource levels. The median across all 10 systems is 6 tiers. Figma, GitHub, Atlassian, and Notion each have 7 tiers but structure them differently: Figma ties roles to billing (Full at $20/mo, Dev at $15/mo), while GitHub splits 2 org roles from 5 repo roles.
Target 4 to 7 role tiers for most products. Fewer than 4 forces over-permissioning; more than 8 creates confusion without adding meaningful access control.
Role Models
8 of 10 systems use two-layer roles with org and resource levels
The majority of systems separate org-level roles (controlling workspace access) from resource-level roles (controlling what you can do with a specific file or project). Only Slack and Linear use flat org-level roles, meaning your workspace role determines everything — you cannot grant someone "Editor" on one project but "Viewer" on another. This forces over-permissioning, giving everyone broad access to avoid blocking people. GitHub demonstrates the strongest two-layer model: 2 org roles (Owner, Member) paired with 5 repo roles (Admin, Maintain, Write, Triage, Read).
Use a two-layer model (org roles plus resource roles) if users need different access levels per project or file. Flat models work for small teams but force over-permissioning at enterprise scale.
Role Models
Only 3 of 10 systems support custom roles, all behind Enterprise plans
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Role Models
Atlassian is the only system using group-based permission assignment
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Invite Flows
Only 4 of 10 systems offer invite links as an alternative to email
Trello, Figma, Slack, and Airtable offer shareable invite links alongside email invitations. Trello shows "Invite with link" as a secondary option with the collaborator limit ("1/10") visible. Figma offers both email and link tabs in the same modal with configurable permission levels per link. Airtable adds a domain restriction option to its invite links, limiting access to specific email domains.
Offer invite links as a secondary option alongside email for broad onboarding scenarios. Always pair links with permission controls and consider domain restrictions for security.
Invite Flows
Dropbox is the only system that asks about admin data access during team join
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Share Dialogs
5 of 6 systems with share dialogs offer three-tier visibility controls
Share dialogs follow a consistent three-tier visibility model: restricted (only people invited), organization-wide (everyone at the workspace), and public (anyone with the link). Notion labels these "Only people invited," "Everyone at casestudyclub," and "Anyone on the web with link." Every system defaults to the most restrictive tier. No system defaults to public or org-wide access.
Build your share dialog with three visibility tiers: private, organization, and public. Always default to the most restrictive option. Let users explicitly escalate visibility.
Share Dialogs
Dropbox assigns per-folder permissions during the invite flow itself
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Access Denied
Only 4 of 7 systems offer a recovery path on access-denied pages
Of the 7 systems with access-denied surfaces, 4 offer actionable recovery paths: request access, switch accounts, or contact an admin. The remaining 3 leave users at a dead end with no way to self-resolve. Notion provides the strongest pattern: a "Request access" button, a "Back to my content" escape, and the logged-in account displayed at the bottom. Airtable is the worst offender, showing only "Sorry, we were unable to accept the invite" with no CTA, no explanation, and no next step. Dead-end denied pages generate avoidable support tickets.
Always include at least one recovery path on access-denied pages. Show a 'Request access' button as primary CTA and the logged-in account with a switch option as secondary. Never leave users at a dead end.
Access Denied
4 of 7 systems show the logged-in account on access-denied pages
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Access Denied
GitHub is the only system that shows 404 instead of 403 for private resources
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Request Access
5 of 10 systems have no request-access flow at all
GitHub, Slack, Linear, Airtable, and Asana offer no way for a blocked user to request access. If you lack permission, your only option is to contact someone outside the product via email, Slack DM, or walking to their desk. Of the 5 systems that do have request flows (Figma, Notion, Dropbox, Trello, Atlassian), 4 show the logged-in account and offer account switching on the request page.
Build a request-access flow even if it is minimal. A 'Request access' button on the denied page that notifies the resource owner eliminates side-channel communication and gives admins a structured approval workflow.
Request Access
Figma and Notion surface access requests inline inside existing UIs
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Request Access
Atlassian is the only system that discloses data sharing when requesting access
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Destructive Actions
'Remove' is the consensus CTA for destructive actions at 6 of 9 systems
Six of 9 systems use "Remove" as the primary verb for revoking someone's access. Notion uses "Continue," Slack uses "Deactivate," and Linear uses "Confirm." "Continue" is the worst offender because it is the standard CTA for proceeding through a multi-step flow, not for removing someone. "Confirm" is equally vague because it does not describe the action being confirmed. GitHub takes the best approach by embedding the username in the CTA itself: "Remove haalandjan from this repository," eliminating any ambiguity about who is being removed.
Use "Remove" as your destructive action CTA with the person's name in the button text. Never use 'Continue' or 'Confirm' for actions with irreversible consequences — the CTA should describe the specific action being taken.
Destructive Actions
4 of 9 systems use a question format for removal confirmation headlines
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Destructive Actions
2 of 9 systems offer granular removal with multiple scope options
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Decision Frameworks
7 of 9 systems use inline role descriptions in dropdowns
The dominant pattern for presenting roles is a dropdown where each option includes a 1 to 2 sentence capability description. GitHub shows 5 repo roles (Read, Triage, Write, Maintain, Admin) each with a clear one-sentence summary. Slack and GitHub are the only 2 systems that also offer a full permission matrix with all roles as columns and permissions as rows. Atlassian is alone in using group-based assignment.
Use inline dropdown descriptions as your default for role selection. Add a one-sentence capability summary per role. Reserve permission matrices for admin settings where granular comparison matters.
Destructive Actions
Only 4 of 9 systems explain what the person loses during removal
Data, screenshots, and actionable recommendations. Unlock this and every Pro insight.
See plans →Anti-Patterns
Why 'Authentication error' fails as an access-denied headline
Linear is the only system that uses technical language ("Authentication error") as its access-denied headline. Users do not think in HTTP status codes or auth protocols. The word "authentication" sounds like something is broken, not that they lack permission. Notion uses "No access to this page" and Asana uses "It looks like you don't have access to this," both of which explain the situation in plain language.
Use direct, non-technical language for access-denied headlines. "No access to this page" beats "Authentication error" or "403 Forbidden" every time.