Figma sharing access guardrails pattern — Hovvi

What happened

Treat who-can-access and what-they-can-do as independent choices made together at share time, keep seats and permissions as distinct grants, expose viewer lock-down as an explicit per-file exception, and document that revocation removes only the explicit grant. Make audience scoping and capability tiers legible in one share surface before any invitation is sent.

Evidence

Observed facts

• The share modal scopes file access through an explicit audience ladder: Anyone, a named organization (Organization/Enterprise plan only), a named workspace (Enterprise plan only), or Only invited people.
• Audience scope is chosen separately from capability: after picking who can access, the sharer sets what they can do — view or edit.
• Paid plans add per-file hardening options: password protection, control over whether the file appears in organization search results, and Enterprise-only link expiration.
• A prototype-only link presents flows for clients, stakeholders or usability testing without exposing the source design file; prototype-only links are paid-plan features and on Starter the viewer can still open the source file from presentation view.
• The permissions list in the share modal shows only explicitly invited people, not everyone who holds inherited access through organization, team or folder membership.
• An organization admin can disable public links entirely; when that happens the Anyone option stops appearing in member share settings.
• Permissions are two-tier — can view (read-only actions including inspecting properties, following and commenting) versus can edit — applied independently at file, folder and team levels.
• Access granted at a higher level inherits to everything inside it, while an explicit grant at a lower level can raise one person's access on a single resource above what they inherit.
• Seats and permissions are separate grants: editing a file requires both an appropriate seat and can-edit permission, and seat requests are approved according to admin seat-approval settings.
• Sharing spans an asset hierarchy — prototype, file, folder, team, plan — with team-level links restricted to Organization and Enterprise plans.
• By default anyone with can-view access can copy, share and export a file's contents; a single per-file Advanced setting reverses this for all viewers, invited or link-joined, and cannot be applied to multiple files at once.
• Removing someone only strips their explicit grant: they disappear from the share list and lose direct open/edit access, but any inherited path through organization, team or folder keeps working and they may keep receiving email notifications on earlier comment threads.
• Admins and anyone with can-edit on a resource can adjust or revoke others' access from the same share modal used to grant it, with per-person permission dropdowns.

Editorial inference

• Keeping audience and capability in one modal makes the safest low-effort choice visible because a sharer cannot pick a scope without also seeing its consequences.
• Because default viewer powers stay open and inheritance survives removal, teams needing strict containment must treat lock-down and inheritance audits as setup tasks rather than runtime reactions.

Evidence views

1. Share modal with audience ladder
2. Capability tier selection
3. Advanced viewer-restriction toggle
4. Revoked-person state with inherited-path notice
5. Admin-disabled public link state

Founder takeaway

Decide who-can-access and what-they-can-do as separate visible choices, and tell users which paths survive revocation.

Use when

• A collaborative content product shares work with external stakeholders under time pressure
• Enterprises demand confinement while individuals expect open-by-link convenience
• Higher-priced tiers should visibly add hardening rather than basic collaboration
• Audit tooling needs to distinguish explicit grants from inherited membership

Avoid when

• Users share nothing beyond their own account and no scoping vocabulary is needed
• Regulation requires deny-by-default with centrally approved exceptions
• Inheritance is technically impossible, making removal semantics misleading

Next implementation step

Design a sharing flow where scope, capability, hardening and revocation are each an explicit reviewed step before an outsider opens content.

Acceptance criteria

• A sharer can state who will get in and what they may do before sending anything
• Removing a collaborator explains remaining inherited paths in-product
• Viewer lock-down reflects globally on the file without partial states
• Paid hardening never hides basic scoping controls
• No evidence artifact contains private organizational data

Related cases

• Platform evidence policy versus per-resource access scoping: Polymarket inline evidence trust pattern — Hovvi

  Both references ask how much context an outside party may reach without formal membership: Polymarket decides whether inline citations travel with the answer, while Figma lets owners choose between Anyone, Organization, Workspace and invited-only audiences before granting view or edit.

• Trust defaults users meet first versus explicit access actions: Cloudflare Workers Playground first-run flow — Hovvi

  Cloudflare makes the first-run failure recoverable inside an anonymous-safe playground, while Figma documents which viewer powers stay open by default and how owners close them; both keep the trust-relevant action explicit instead of silent.

Version history

Current snapshot: snap_figma_sharing_access_2026_08_27 — Added Figma's second bounded Task Reference on content-sharing access control using public Help Center documentation as link-only evidence; authenticated admin console imagery stays excluded.

Use with an Agent

Example read-only MCP query: