Get the work out
Handoff to a client
Four ways to hand work over, and the one that answers the questions a client asks three weeks later.
The work is approved and now somebody else needs it. What to send depends on whether they are looking at it, reviewing it, or building on it. ## Four routes | Route | Good for | They get | |---|---|---| | **Public link** | Review and comment cycles | The live board, read-only, updating as you work | | **Embed** | A page you maintain | The same board inside your own context | | **Frame export** | The approved set | A clean bundle of only what was signed off | | **Whole-board bundle** | Full handover | Everything, including the notes and the reasoning | ## For a review Send the public link. It needs no account, it stays current as you work, and it hides everything about how the work was made: no tool cards, no in-progress pills, no cursors. The thing to decide before sending is whether "stays current" is what you want. A link sent on Monday shows Thursday's half-finished experiment, so for a fixed review, make a board that holds only the approved work and share that instead. :::tip[Make a presentation board] Duplicate the approved directions onto their own board, frame them, lock them. A client never sees a dead end, and you send the same thing every round instead of deciding what to share each time. ::: ## For a delivery Frame the approved work and export the frame, or bundle the whole board when they should have everything. The bundle is the more generous option, because it carries the parts that are not files: sticky notes as `notes.md`, references as `links.md`, colour palettes as `palette.txt`. A client receiving that gets the decisions alongside the deliverables. ## The question that arrives three weeks later "Which settings made this one?" or "can we use this commercially?" Both are answered by the asset itself. Every file carries its record: the tool, the model, the exact prompt, the settings, the date. Right-click for Properties and it is all there, including on an asset nobody remembers making. That is worth telling a client explicitly, because most of them expect the answer to be "let me ask the designer who has since left". :::note[The record is not written into the file, and it still comes back] Nothing is embedded in a downloaded PNG, so a client opening it in another application sees an ordinary image. Bring that same file back into Plnty, though, and it is recognised by its bytes and reattached to everything it knows. See [when a file comes back](/docs/using-plnty/the-asset-library/when-a-file-comes-back/). The practical consequence for a handover: a client who needs to read the provenance themselves needs access to the board or the answer from you. The team chapter covers that in [provenance for compliance](/docs/team-spaces/provenance-for-compliance/). ::: ## Before you send anything 1. **Rename the assets you are shipping.** Names follow files into the download 2. **Check transparency.** A cutout keeps its alpha as PNG and loses it as JPG 3. **Remesh any generated 3D**, so what arrives is workable rather than a job 4. **Look at what a viewer sees.** Open the public link yourself before sending itThe work is approved and now somebody else needs it. What to send depends on whether they are looking at it, reviewing it, or building on it.
Four routes
Section titled “Four routes”| Route | Good for | They get |
|---|---|---|
| Public link | Review and comment cycles | The live board, read-only, updating as you work |
| Embed | A page you maintain | The same board inside your own context |
| Frame export | The approved set | A clean bundle of only what was signed off |
| Whole-board bundle | Full handover | Everything, including the notes and the reasoning |
For a review
Section titled “For a review”Send the public link. It needs no account, it stays current as you work, and it hides everything about how the work was made: no tool cards, no in-progress pills, no cursors.
The thing to decide before sending is whether “stays current” is what you want. A link sent on Monday shows Thursday’s half-finished experiment, so for a fixed review, make a board that holds only the approved work and share that instead.
For a delivery
Section titled “For a delivery”Frame the approved work and export the frame, or bundle the whole board when they should have everything.
The bundle is the more generous option, because it carries the parts that are not
files: sticky notes as notes.md, references as links.md, colour palettes as
palette.txt. A client receiving that gets the decisions alongside the deliverables.
The question that arrives three weeks later
Section titled “The question that arrives three weeks later”“Which settings made this one?” or “can we use this commercially?”
Both are answered by the asset itself. Every file carries its record: the tool, the model, the exact prompt, the settings, the date. Right-click for Properties and it is all there, including on an asset nobody remembers making.
That is worth telling a client explicitly, because most of them expect the answer to be “let me ask the designer who has since left”.
Before you send anything
Section titled “Before you send anything”- Rename the assets you are shipping. Names follow files into the download
- Check transparency. A cutout keeps its alpha as PNG and loses it as JPG
- Remesh any generated 3D, so what arrives is workable rather than a job
- Look at what a viewer sees. Open the public link yourself before sending it