Figma Permissions Cascade Downward

Why it exists

Design work in Figma happens across many files and projects, so the platform needs a way to manage who can see or edit what without setting permissions on every single file manually. The solution is a hierarchical permission system where access granted at a higher level automatically flows downward to everything contained within it. This reduces administrative overhead but introduces the risk of over-sharing if you choose the wrong level.

The mental model

Think of Figma permissions as nested boxes. The organization is the largest box, followed by teams, then projects, and finally individual files and prototypes. When you place someone inside a box, they can see everything in that box and all the smaller boxes inside it. You cannot hide a file inside a project from someone who has access to that project. The level you invite them to is the ceiling of their visibility.

How it works

There are three ways to share. First, you can copy a share link. Second, you can send a direct invitation using an email address. Third, you can embed a file or prototype in an external website. Share links and invitations behave differently depending on the resource. For example, team invite links are included by default, but project share links are not. Team admins can reset or disable invite links to revoke unredeemed access. When you invite someone directly to a file, they get access only to that file. When you invite them to a team, they get access to every project and file in that team, with either can view or can edit rights.

When to use it

Use team-level invitations for core collaborators who need ongoing access to multiple projects. Use project-level invites when a contractor needs to work across several related files. Use file-level invites for one-off reviews or when you need to share a single deliverable without exposing the broader workspace. Share links are fastest for stakeholders who already have Figma accounts and just need to jump in.

When not to use it

Do not invite someone to a team if they only need to comment on one file, because you will expose every project and file in that team. Do not rely on project-level restrictions to hide sensitive files from team members, since team access overrides project boundaries. Do not send open share links for confidential work without checking the default organization or team link settings first.

One canonical example

A product manager needs to review a single prototype. If you invite them to the product team, they can now browse every design file, every research deck, and every exploratory concept in every project. If you instead send them a link to just that prototype file, they see only what they need. The five seconds you save by inviting them to the team can cost hours of cleanup later.