Lock file from receiving updates from library (for archive)

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:

• This file becomes a Version X1 for Q1 2023 production
• If there’s a bug, that’s considered a fix and should be local
• If we need to develop for another phase/sprint, then we were duplicate the file and create Version X2

Some options/steps on my mind for locking down the file:

• Duplicate the current file and create the next version (see above)
• Turn off all Figma Library subscriptions
• Indicate delivery date on Thumbnail
• Add an explanation on our Cover Page
• And, possibly, lock layers on all pages

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.