Skip to main content
Anne13
Anne13
March 14, 2024

Accept library updates per page

  • March 14, 2024
  • 25 replies
  • 1617 views

It would be very helpful if we could accept library updates per page, so that we can exclude some pages from being updated (ready for dev) while accepting the updates for other pages (design WIP pages).

In our Figma files we have separate pages ‘Ready for dev’ to which no changes should be made after handoff. But we want to continue designing on other pages in the same file (working on new iterations), so we want to be able to accept component updates from the library. But these updates are automatically applied to every page in the file, which means the ‘Ready for dev’ designs are also modified and sometimes even break.

I do not want to have to make a separate file for every time I hand over a design, because I want to keep all designs for a specific feature together in 1 file.

A solution would be to be able to accept library updates for specific pages rather than all pages. What do you think about this?

Similar (closed) topics that I’ve found:

    25 replies

    Show previous replies
    Apolline
    Apolline
    Active Member
    February 4, 2025

    Well it’s kinda crazy because I have the opposite issue 😓 I keep clicking “show updates for all pages”, and it doesnt update all of them at once. The library manager is just broken.

    Griffin1
    Griffin1
    New Participant
    February 4, 2025

    ​@Lauren_Shupp3 I’m glad you found a workaround! Though wouldn’t the number of components and versions of components in a library grow exponentially over time? Sounds really hard to manage, especially when you have multiple files inheriting from one library.

    ​@Apolline Yeah I’ve had similar issues, though reloading a tab before applying changes from libraries seems to help some.

    Shaun_McHugh1
    Shaun_McHugh1
    New Member
    February 5, 2025

    I’ve also encountered this issue projects I’ve been working on. It is somewhat of an Achilles heel within Figma, trying to have designs which don’t change for dev, QA, and archival purposes. (There were many disadvantages of Zeplin but it handled handover and archival pretty well)

    One way I’ve found to manage it is by using the branching system in an unconventional way. At the end of every sprint we create a new branch in the handover file, and add the designs of that sprint to the new branch. After sprint is complete we don’t accept any updates from library. 

    It’s pretty much the same as having a separate file for every sprint handover (which is what I’d recommend if branching not available), but the branches reduces the number of files we have.

      Lauren_Shupp3
      Lauren_Shupp3
      New Member
      February 5, 2025

      ​@Lauren_Shupp3 I’m glad you found a workaround! Though wouldn’t the number of components and versions of components in a library grow exponentially over time?


      Hello!  Yes this is the issue with Figma not formally supporting this. lol

      I think to avoid this we can unpublish the older versions of the component when ready. I’m still exploring the best way to do this. I think this would effectively “break” project mockups from the library, but I’m NOT sure. I’m curious if republishing them would bring that connection back. Before trying this and risking bulk detachment, I’m going to let some time pass to make sure the link isn’t needed anymore.  I could also just setup some dummy components and try this out...

      Julia57
      Julia57
      Active Member
      July 9, 2025

      ​@Shaun_McHugh1
      Does this mean each sprint is a separate branch, and those branches just stay there forever in order to serve as a history log? So your file coudl one day have 25 branches??

      Terms & ConditionsAccessibility statement