I need to create an archive, where I can duplicate my files and prevent them from being updated. Can I prevent library updates from being received in a specific file? Or do I have to detach everything every time I create a copy?
Detaching would be bad for the DS stats.
Thanks!
Iâm not sure if the permission options change depending on the plan youâre on, but my suggestion would be to create either a Team or Project within a Team that only you or a trusted circle of others have edit access to. Everyone else would have view access. The files you duplicate for archiving would be stored here, still attached to your component libraries, but there would be an expectation that component updates are NOT to be accepted. If you limit the number of people that have edit access this should be easy. And luckily even if someone does mistakenly update the components within an archived file you always have version control to roll back.
With all due respect, I donât believe this is an effective solution in the long run. It requires an agreeement and hacks like adding âDONâT UPDATEâ the filename. Also, teammembers come and go. Archiving files using versioning requires consisent and widely accepted and followed standardsâwhich is very difficult to enforce at scale. So accidental updates are very likely and tricky to âroll backâ.
A much better solution would be to allowing pages, or even entire files, to be locked from receiving any library updates. I.e., active editors would still see the âUpdate availableâ toasts, but the the Review button would be deactivated and a message reminding them that the file or page is locked. If they had the permissions (such as Team Owner), they could unlock it.
This feature would be especially helpful when handing off files to devs.
Tristan, I agree! Having features that offer the locking control youâve described would be better. This is a great suggestion for the âShare and Ideaâ part of the forum. But since we only have whatâs built today, I donât know that a âit would be better if X existedâ reply is all that actionable, because X-feature doesnât exist yet.
For now, the way I see it, safeguarding archived files in Figna is all honor-system based and manually managed. One way to look at this is that itâs an opportunity for a team to practice co-creating documentation and expectations about their design process.
Same kind of question here. Weâre still transitioning out of Zeplin, which provides a publishing platform for static wires. The âpublish stepâ to get things out of Figma is not desired, but we also want to protect the deliverables from being tampered with.
File versioning:
Some options/steps on my mind for locking down the file:
I doubt this helps, but pondering the same kind of things. Thinking⌠I will do all these steps, the Figma will release a solution. 
We are trialing a different process for this.
We download the whole file locally, then save one copy for our Web App (mentioning the app version), and then save another copy for our Mobile App (again mentioning the app version).
We are trialing this, so that before each design up the local copy is saved to âversion controlâ and save the the current design.
Anymore ideas or updates here? I manage our design system and have a team that wants to detach everything (using a plug-in called destroyer) in order to have accurate archived files for releases, but as the original poster mentioned, that will ruin our detaching metrics.