Summary

  • Either party can disconnect a Figma connected folder. The folder stays with the host, while the external team loses access to its files.
  • Sending a copy leaves comments, version history and branches with the originals. A folder transfer and a delivery of copies buy different things.
  • A library left behind stops supplying updates to transferred files. Moving the published library instead cuts off updates to files remaining with the sender.

The handover looks excellent in a screenshot. Every button is the right colour. Every card has the right corners. The client signs off, the agency closes the job, and the replacement designer arrives with a modest request: change the original component so all those buttons change together.

Now the screenshot has very little to say.

Consider a hypothetical agency engagement run through a Figma connected folder. Both businesses pay for their own seats. Both have people making changes. The arrangement feels like a shared workshop, and in daily use it is. But somebody opened the workshop and invited the other business inside. Figma calls that party the host. At the end of the engagement, the distinction has teeth.

The exit door works for both parties. The originals stay on one side

Figma's connected-folder guide requires paid plans on both sides and approval from both parties' administrators. An appropriate seat and permission to edit are separate requirements. Bringing your own paid seat gets a person equipped to work; it does not give their employer equal control of the room.

The host sets security and privacy conditions, chooses the libraries available to the external team and determines which features are available through its plan. Both parties can create files or bring files into the folder. Only people on the host side can remove files from it.

Either party's administrator can disconnect. Once that happens, the folder remains with the host and the external team loses access to all files inside. The host can leave matters there, share a copy, or transfer the folder later. The power to end collaboration is shared; custody of the working originals after that decision is not.

This is a product permission with a commercial consequence. A contract can allocate intellectual-property rights while the software still requires a particular administrator to deliver the working assets. The final invoice should not be the first occasion on which anybody discovers who that administrator is.

There is another small trap in the word “shared”. When a host makes a library available through a connected folder, the external team receives view-only access to its source file. Using the components in a design and editing the source that supplies them remain different jobs with different permissions.

“We sent the files” leaves a lot unsaid

Figma's transfer documentation separates a transfer from sending a copy. With a copy, comments, version history and branches remain with the originals. The recipient can get the finished picture without the recorded discussion that explains why the picture looks that way.

That matters when a successor has to distinguish an intentional exception from an overlooked inconsistency. A comment about a rejected option may save a fresh round of argument. Its absence does not make the file unusable. It makes part of the previous work unavailable in that delivery.

A folder can be transferred to a Professional, Organization or Enterprise destination. A team transfer requires Organization or Enterprise. During transfer, original file and prototype links continue to work; the folder or team gets a new link. Procurement therefore has a more precise question available than whether the supplier offers an “export”: which object is being transferred, to which destination, with which history?

The client-collaboration guide describes both agency-hosted and client-hosted arrangements. It also says a local file copy imported into another account no longer receives updates from the original team's library. A downloadable file is a useful deliverable. The next month's maintenance service is a separate item.

The library is where the next bill is hiding

A Figma library supplies reusable components, styles and variables from a source file. A published change can be offered to files using those assets. People with editing rights then review and accept or ignore it. The visible design is one moment in that relationship, not the whole relationship.

The transfer rules put a sharp price on treating it as one. Leave a library out of a transfer and its components in the transferred files remain at their last known state, without future updates. Transfer the published library itself and files remaining in the sender's team or organisation stop receiving its updates.

For an agency with reusable components across engagements, handing over the source library can therefore affect work staying behind. For a client buying an independently maintainable design system, taking only the assembled screens leaves future maintenance elsewhere. Both positions are understandable. The architecture needs a boundary that the commercial agreement can describe.

One possible boundary is a client-specific library with a named maintainer. Another is a deliberate fork, with the client accepting responsibility for future divergence. A continuing agency service can work too, if the service and the dependency are actually in the bargain. “All design files included” is doing heroic unpaid labour when it is expected to settle all three arrangements.

Figma has a library-swap tool, but it does not negotiate that boundary. It matches asset names, including component sets and variants. Assets without a match remain linked to the original library. The operation concerns the file being edited; it is not a universal relocation of every dependency across a business.

Matching names also cannot settle whether two components mean the same thing to the product. A button with the right name can still embody a different decision about behaviour or presentation. That judgement belongs to the people doing the handover.

A more useful acceptance exercise follows one agreed change through the intended future arrangement. The new maintainer publishes it from the chosen library; an authorised editor reviews and accepts it in a consuming file. Figma's update review defaults to showing updates for the current page, with an option to show all pages. The scope of the check matters. Admiring one clean page is a poor substitute for knowing which files and pages still depend on a source left behind.

To price an actual exit, the missing evidence is the folder's host assignment, its library-dependency map and the agreed handover terms. Together they would show whether the buyer is receiving a maintainable system, a frozen copy or an ongoing service obligation.