Skip to main content
Vitalii_Sologub
New Participant
September 10, 2026
Solved

Editors lost their edit access after the file was moved to another folder with edit permission

  • September 10, 2026
  • 3 replies
  • 41 views

Yesterday I’ve restructured our Figma projects:

  • Created a folder with “Anyone in Company can edit
  • Added sub-folders with “Anyone in Company can edit
  • Moved existing files into these sub-folders
  • People, who previously could edit these files (through the global full seat), lost their editing capabilities

It seems that after the files were moved they switched to “Anyone can view”.

Why do these files, moved to new sub-folders, have the Share settings different from the old files in old projects?

  • Files in the new subfolders

     

  • Files in the old projects

 

Now, do I need to manually update this permission for 100+ files?!

 

And more

You do know that after the projects to folders transition you removed the project/folder description visibility, right? They still exist in settings, but no one sees them.

Best answer by Gayani_S

Hey ​@Vitalii_Sologub, thanks for reaching out!

Let me walk through how to fix the files you've already moved without going through all 100+ one by one.

Figma folders have two separate layers of access:

  1. The folder's "Who has access" setting (what you configured, the plan-wide "can edit" option). This controls who can get into the folder itself, and it's what new files created directly in the folder will follow by default.
  2. Direct invites on the folder, specific people (or, on Organization/Enterprise plans, user groups) added to the folder's share list with their own can edit or can view permission.

Files that already existed elsewhere before being moved in keep whatever access they already had, moving them into a folder with a broader "who has access" setting doesn't retroactively update them. That's the mismatch you're seeing.
 

To fix this, invite people to the folder directly, not the files. Direct invites on a folder (permission #2 above) are designed to apply to files already sitting in that folder, not just new ones. So this is worth trying before updating 100+ files individually:

  1. Open one of the affected subfolders' Share modal.
  2. Invite the people (or teams) who need edit access directly to the folder, with Can edit permission.
  3. Check whether that restores their edit access on the files already inside.

If that confirms it's working, you can roll it out across the rest of the restructured folders, one invite pass per folder rather than per file.

 

On the Professional plan, an individual file's own "Who has access" setting only offers two options: Anyone (literally anyone with the link, including outside your company) or Only invited people. There's no company-scoped middle option at the file level the way there is at the folder level. If you open one of the affected files and check what "Anyone" says there, and it mentions access for people outside your organization, that's worth knowing on its own, separately from the edit-access question.

For more on how folder and file permissions interact, here's our File and folder permissions guide.

 

On your second point about folder descriptions no longer showing after the projects-to-folders transition, I don't have a confirmed explanation for that one yet, but I'd like to dig into it. Are you seeing this on the folder's own settings page (a description you'd previously entered is saved but just not displayed), or somewhere else, like a list view in the file browser? Let me know and I'll look into it from there.

 

Thank you, 

Gayani 

3 replies

Gayani_S
Figmate
Gayani_SAnswer
Community Support
September 10, 2026

Hey ​@Vitalii_Sologub, thanks for reaching out!

Let me walk through how to fix the files you've already moved without going through all 100+ one by one.

Figma folders have two separate layers of access:

  1. The folder's "Who has access" setting (what you configured, the plan-wide "can edit" option). This controls who can get into the folder itself, and it's what new files created directly in the folder will follow by default.
  2. Direct invites on the folder, specific people (or, on Organization/Enterprise plans, user groups) added to the folder's share list with their own can edit or can view permission.

Files that already existed elsewhere before being moved in keep whatever access they already had, moving them into a folder with a broader "who has access" setting doesn't retroactively update them. That's the mismatch you're seeing.
 

To fix this, invite people to the folder directly, not the files. Direct invites on a folder (permission #2 above) are designed to apply to files already sitting in that folder, not just new ones. So this is worth trying before updating 100+ files individually:

  1. Open one of the affected subfolders' Share modal.
  2. Invite the people (or teams) who need edit access directly to the folder, with Can edit permission.
  3. Check whether that restores their edit access on the files already inside.

If that confirms it's working, you can roll it out across the rest of the restructured folders, one invite pass per folder rather than per file.

 

On the Professional plan, an individual file's own "Who has access" setting only offers two options: Anyone (literally anyone with the link, including outside your company) or Only invited people. There's no company-scoped middle option at the file level the way there is at the folder level. If you open one of the affected files and check what "Anyone" says there, and it mentions access for people outside your organization, that's worth knowing on its own, separately from the edit-access question.

For more on how folder and file permissions interact, here's our File and folder permissions guide.

 

On your second point about folder descriptions no longer showing after the projects-to-folders transition, I don't have a confirmed explanation for that one yet, but I'd like to dig into it. Are you seeing this on the folder's own settings page (a description you'd previously entered is saved but just not displayed), or somewhere else, like a list view in the file browser? Let me know and I'll look into it from there.

 

Thank you, 

Gayani 

Vitalii_Sologub
New Participant
September 10, 2026

Thank you, 
but I am pretty sure that for these specific files:

  • yesterday all designers were able to edit
  • in the evening I simply moved the files, did not edit their permissions
  • today designers lost editing

And regarding your statement:

On the Professional plan, an individual file's own "Who has access" setting only offers two options: Anyone (literally anyone with the link, including outside your company) or Only invited people. There's no company-scoped middle option at the file level the way there is at the folder level. 

This is my experience with the individual file’s sharing on a Pro plan:

 

We had to update permissions for the key files manually.

 
Gayani_S
Figmate
Community Support
September 11, 2026

Thanks for digging into this further and sharing the screenshot!

There are actually two different things showing up in a file's Share modal, and they're easy to mix up:

  1. The file's own "Who has access" setting, the one you'd click and change yourself. On the Professional plan, that's limited to Anyone or Only invited people. The company-scoped middle option only exists there on Organization and Enterprise plans, so that part of my earlier reply was about this specific control.
  2. What the enclosing folder grants, a separate, read-only line the modal shows so you can see what the file inherits from its folder. That's the "Anyone in [company]: can edit" row in your screenshot. It's reflecting your folder's plan-wide "can edit" setting, not a new option living on the file itself.

So you're not wrong that a third state shows up. It's just row 2, not a hidden option on row 1. 

What I can't tell from here is why that folder-level "can edit" wasn't actually reaching the file for your editors before you fixed it manually. That comes down to the specific access history on those files, which isn't something I can see from a public thread. If this shows up again on a future batch and you want us to dig into the "why," the most direct route is a request through our Support Hub with a couple of the affected file links, that gives the team the access to actually trace it.

One thing that'd help either way: when you invited people directly to the folder, did that restore editing on any of the files already sitting inside it? That'll tell us whether that route is worth using on the rest of your 100+, or whether file-level fixes really are the only way through this particular batch.

For more on how the two layers interact, here's our Share files and prototypes guide.

Thank you,
Gayani