Skip to main content
Erik23
Erik23
New Member
September 8, 2026
Solved

Access inheritance not working for new users in the team

  • September 8, 2026
  • 6 replies
  • 136 views

As an admin on a professional plan of a small team I have an issue where new team members won’t get access to pre-existing files/folders.

I need to manually grant access to each and every file which is not sustainable. Inheritance of team (role) access doesn’t seem to be working properly.

  1. If sharing is set to “Anyone can view” the employees (as full members) must request to edit.
  2. If sharing is set to “{team name}” and “Edit” it works, but then the clients can’t access 
  3. If sharing is set back to “Anyone can view” the edit rights for the employee is gone.

Despite being a full member in the team and a full seat, the new employee is not added to the automatic “Share this file” > “People from {team}”.

 

Am I doing something wrong or is this a bug?

    Best answer by djv

    Hi ​@Erik23 and ​@Lauri_Incrosnatu, thank you for reaching out about this! 

    I understand the frustration and how this is slowing down your workflow. There are two situations happening here, so I’d be happy to help clarify.

     

    Why new members don't get access: access can come from two places, and they behave differently. A role (being invited directly to a folder or file) is inherited by everything underneath it. A sharing audience setting like "Anyone in [team] can edit" applies only to the item it's set on; it doesn't cascade to the files inside. So a file set to "Only invited people" sitting in a folder set to "Anyone in [team] can edit" stays locked until that person has a role somewhere in the chain. That's why the folder looks visible but empty.

    A temporary solution that scales: create one parent folder, nest your existing folders inside it, and invite people at that top level. As long as inheritance isn't broken further down, roles flow to everything underneath, including files added later. That solves the "every new hire" problem without touching files one at a time, and it works for a freelancer you want scoped to one area too.

     

    For the invite that vanished, an invited person getting a "request access" screen with no request reaching you isn't expected behavior. Could you file a ticket with the file link, the team name, the email you invited, and roughly when this happened? The team would be happy to look into this. 

    6 replies

    Lauri_Incrosnatu
    Lauri_Incrosnatu
    New Participant
    September 8, 2026

    You are not doing anything wrong. Figma changed the logic, leaving us with Professional plan in a bad situation, as their previous (default) access settings worked in a way that new team members automatically were able to access and edit all files.

    I’ve been trying to sort this out for for a while, but so far the answers from Figma have been “oh, you have set only people invited to files...” and they are not really seeing the problem or providing us with any solution.

    I showcased the issue here on this thread: 

    We don’t use the “anyone” setting that much, but I now realize that this use case, where you want to quickly link a file with the “anyone can view” setting for clients, is a perfect example of how bad this new logic is. Because new employees are now excluded from the “collaborators list”, they would not be able to edit these files at all. You would have to add every new employee as an editor to every file each time someone is hired, potentially across hundreds or thousands of files.

    I think the migration was done in a very poor way. I’d say most small teams would want their team members to have access to old files by default, and this new logic completely destroys that. There is no way for us to mass-edit permissions and it’s riddled with these type of silly issues. For the past week, I’ve been changing the access permissions of critical files one by one so that new employees can access them. The use case you just mentioned is even worse, because there is no way to set files in a way that would automatically include new employees in the future, and this issue is not only for old files or folders done before the migration, it’s for new ones as well.

    Please Figma, help us out here!

      Erik23
      Erik23Author
      New Member
      September 8, 2026

      Figma changed the logic, leaving us with Professional plan in a bad situation, as their previous (default) access settings worked in a way that new team members automatically were able to access and edit all old files.

      I’ve been trying to sort this out for for a while, but so far the answers from Figma have been “oh, you have set only people invited to files...” and they are not really providing us with any solutions.

      I showcased the issue here on this thread: 

      We don’t use the “anyone” setting that much, but I now understand that this use case, where you want to link a file with the “anyone can view” setting for clients, is a real problem because new employees are excluded from the “collaborators list”, meaning that they would not be able to edit these files at all. You would have to add new employees as editors to every file every time someone is hired, potentially across hundreds or thousands of files.

      I think the migration was done in a very poor way. I’d say most small teams would want their team members to have access to old files by default, and this new logic completely destroys that. There is no way for us to mass-edit permissions and it’s riddled with these type of silly issues. For the past week, I’ve been changing the access permissions of critical files one by one so that new employees can access them. The use case you just mentioned is even worse, because there is no way to set files in a way that would automatically include new employees in the future, and this issue is not only for old folders done before the migration, it’s for new ones as well.

      Please Figma, help us out here!

      Thank you for the reply and pointing me towards the other thread (I was unable to find similar issues before). I fully agree with you. This could - and should - have been handled better. As we’re quite reliant on all team members accessing all designs while we’re frequently showcasing design to clients, this is basically a showstopper without manually granting access to all individual projects. I’ll repeat after you: Please Figma, help us!

      Lauri_Incrosnatu
      Lauri_Incrosnatu
      New Participant
      September 10, 2026

      Yep.

      Today we were unable to invite a freelancer (with limited access) to a single file that had the “Anyone in [team]” as it’s permission. When adding a person with email, the person did get the link and got the request access view, but we did not get the access request or even see the person invited to the file in the share modal. We tried this multiple times and eventually had to add the freelancer to the whole folder for it to work.

      I just tried the same with my test-account and same happened, the access request sent by the invited user shows nowhere in Figma to be approved!

      The whole access system seems to be broken and for the past week it has been a nightmare managing these issues.

      djv
      Figmate
      djvAnswer
      Community Support
      September 10, 2026

      Hi ​@Erik23 and ​@Lauri_Incrosnatu, thank you for reaching out about this! 

      I understand the frustration and how this is slowing down your workflow. There are two situations happening here, so I’d be happy to help clarify.

       

      Why new members don't get access: access can come from two places, and they behave differently. A role (being invited directly to a folder or file) is inherited by everything underneath it. A sharing audience setting like "Anyone in [team] can edit" applies only to the item it's set on; it doesn't cascade to the files inside. So a file set to "Only invited people" sitting in a folder set to "Anyone in [team] can edit" stays locked until that person has a role somewhere in the chain. That's why the folder looks visible but empty.

      A temporary solution that scales: create one parent folder, nest your existing folders inside it, and invite people at that top level. As long as inheritance isn't broken further down, roles flow to everything underneath, including files added later. That solves the "every new hire" problem without touching files one at a time, and it works for a freelancer you want scoped to one area too.

       

      For the invite that vanished, an invited person getting a "request access" screen with no request reaching you isn't expected behavior. Could you file a ticket with the file link, the team name, the email you invited, and roughly when this happened? The team would be happy to look into this. 

        Lauri_Incrosnatu
        Lauri_Incrosnatu
        New Participant
        September 10, 2026

        Why new members don't get access: access can come from two places, and they behave differently. A role (being invited directly to a folder or file) is inherited by everything underneath it. A sharing audiencesetting like "Anyone in [team] can edit" applies only to the item it's set on; it doesn't cascade to the files inside. So a file set to "Only invited people" sitting in a folder set to "Anyone in [team] can edit" stays locked until that person has a role somewhere in the chain. That's why the folder looks visible but empty.

        A temporary solution that scales: create one parent folder, nest your existing folders inside it, and invite people at that top level. As long as inheritance isn't broken further down, roles flow to everything underneath, including files added later. That solves the "every new hire" problem without touching files one at a time, and it works for a freelancer you want scoped to one area too.

         

        I think the bottom line is that it’s very weird that team members would need to be added anywhere. It should work the other way around, where you could limit access for team members if needed. Creating a new folder level as a workaround for this feels very wrong and, again, not sustainable. We really appreciate the new subfolders, but this new access logic is simply bad. The old logic worked great, where team members automatically had edit access to all files.

         

        For the invite that vanished, an invited person getting a "request access" screen with no request reaching you isn't expected behavior. Could you file a ticket with the file link, the team name, the email you invited, and roughly when this happened? The team would be happy to look into this. 

         

        There is now a ticket for this (#2123718)

          djv
          Figmate
          djv
          Community Support
          September 10, 2026

          Thanks for letting me know, ​@Lauri_Incrosnatu!

          I’ve added context for the team on my side to your ticket #2123718. The team will review and be in touch as soon as they’re available. 

            Terms & ConditionsAccessibility statement