How to document ComfyUI work for client delivery

Example assignment: another artist needs to change the background of a selected product render while preserving its lighting and framing. Begin with the selected output and the graph saved for it. A canvas changed after the render may describe your next experiment instead of the file you are sending.

Keep the technical package and the selection decision connected by one shot and version identifier. The package lets the artist inspect or run the graph. The decision tells them which result to continue and what the new work should preserve. If your workflow already contains that instruction in a Note or MarkdownNote, keep it with the export and check that it still applies to the selected version.

What ComfyUI stores on its side

• A workflow can be exported as JSON independently of the generated media. Source
• Embedded workflow contains the visual graph; prompt is the execution-oriented API representation. A file may contain one without the other. Source
• Built-in save paths support metadata in PNG, animated PNG/WebP, MP4 and WebM, among other formats. Support depends on the node and writing path; metadata can be disabled or removed later. Source
• MarkdownNote adds formatted human annotations to the workflow without generating an output. Source
• A workflow can depend on external input assets, models, custom nodes and their Python dependencies. Retaining the graph does not bundle that environment. Source

What gets lost without your own record

• The connection between the selected render and a later edited canvas can become ambiguous. Save the matching graph with a clear version identifier before continuing the experiment.
• A model filename is not an archive of its weights. Retain an inventory that identifies the actual checkpoint, VAE and LoRAs you used, plus accessible copies or download sources where sharing is permitted.
• A workflow note can hold the selection reason, but the reason only exists if someone writes it. Include the decision in the recipient's package even when they will review the image without opening ComfyUI.
• An internal selection and a client approval can refer to different versions. Keep the reviewer, decision date and exact reviewed file connected, and identify a later revision as a new version.

The documentation checklist for ComfyUI

1. Choose the output you intend to hand over. Give it a shot and version identifier and export the matching visual workflow JSON before changing the canvas.
2. Inspect the original output and the delivery copy. Keep the original when you create a compressed or edited delivery; verify available workflow metadata instead of assuming every file retains it.
3. List required checkpoints, VAEs, LoRAs and their locations. Add hashes when useful for distinguishing local files with the same name, without presenting a hash as proof of generation history.
4. Keep input images, masks and other required assets accessible. Record the ComfyUI and custom-node versions used, and any installation instructions the receiving environment needs.
5. Write a short selection note: which render was chosen, what makes it suitable, what the next change should preserve and who reviews the revision. A workflow annotation can carry this note; a client-facing handoff also needs a readable copy or link.
6. Ask the receiving artist to open the retained graph and resolve its dependencies. If rerunning is part of the assignment, record the test outcome and any substitutions before treating the package as ready.
7. Review sharing scope. A client approving an image may not need model files, internal prompts or all source assets. Agree what can be transferred and inspect the actual files or share they receive.

Behind The Workflow gives this ComfyUI record a practical home: keep an asset with the prompt, model, references, versions and decisions your team adds. Upload or explicitly capture the available details, fill the gaps, and review the record before handoff. BTW does not automatically reconstruct an external generation history or verify reference rights.

For the background-revision example, a useful instruction is: use the selected version as the visual target; preserve the product framing and lighting direction; change the background; return a new version for review. Put the actual file and source-graph links beside that instruction. This gives the receiving artist a starting point without pretending that a graph can infer why the team chose the image.

BTW is built to keep that production context with the asset and its versions. Start with the original output, review any supported imported details, and add the selection reason. Keep the retained ComfyUI workflow and dependency package accessible from the production record. BTW does not run your ComfyUI environment or guarantee that a recipient can recreate an identical result.

If your current folder, annotated graph and review link already make this handoff clear, use them as the baseline. Test whether another artist can find the selected file, the matching workflow and the next instruction in each setup. That is a more useful comparison than counting how many fields a tool can store.

Frequently asked questions