15 October 2026 · The production handover
Furniture drawings: which revision is ready for production?
The newest file is not necessarily the released reference.
Open the release record ↓
The workshop has a PDF. The designer has a newer PDF. Procurement has an email saying that the sample looks right. All three records may be useful, yet none should be assumed to mean the same thing.
Before furniture production begins, the practical question is not simply whether a drawing is recent. It is whether the team can identify the agreed reference, its intended use, the decisions it contains and the person responsible for releasing it. A clear drawing can still be waiting for a decision. A well-photographed sample can still belong to an earlier revision.
This guide is for design, procurement and workshop teams coordinating furniture development. It offers a working method for keeping the handover legible. It is not a drawing standard, an engineering approval or evidence that a product meets a particular requirement. The aim is modest: help the next person work from the reference the team actually intended.
A date does not tell you the status
Imagine receiving two files with the same furniture name. One arrived yesterday and contains a revised arm profile. The other arrived last week and was expressly released for the sample build. The newer file might be a proposal, a review copy or a replacement production reference. Its arrival time cannot settle that question.
Ask the sender to state what the file is for. Useful descriptions might include quotation, design review, prototype construction or production. These are suggested labels, not a compulsory industry vocabulary. The important point is that the people receiving the file understand the same permitted use.
Onshape's release-management documentation offers a helpful software example. It distinguishes a version that records progress from objects with states such as pending or released. Its approval rules depend on the company's chosen workflow. A team using ordinary folders can still make that distinction explicit without adopting the software or copying its terminology.
Put the intended use beside the document reference, rather than leaving it in an email subject that may disappear when the attachment is forwarded. When the use is unclear, resolve that uncertainty before treating the file as production authority.
Identify the object and the whole drawing set
A collection name is rarely enough to identify the work. The reference should distinguish the furniture model and relevant variant, then connect that identity to a drawing number and revision. Where a set contains several sheets, make clear which sheets belong together.
This matters when the overall view and a detail sheet travel separately. A chair outline may remain familiar while the fixing detail changes. Someone checking only the opening sheet can miss that the packet contains references from different stages. The same problem can arise when a screenshot removes the title block.
Autodesk's drawing revision article, published in 2022, describes both drawing-level and sheet-level revision scope. It is a documented example of why a revision identifier needs context, not a claim that every drawing system behaves alike. Ask whether the revision applies to the entire set or to individual sheets.
For a collection with multiple sizes, connect the packet to the appropriate variant rather than expecting the workshop to infer it from appearance. Our guide to collection size variants explains the separate identity and review questions that belong to each version of a design.
Make the change easy to find
A revision letter says that something has changed. It does not necessarily explain what changed, why it changed or which adjacent decisions need attention. Add a short description that a recipient can understand without comparing every line on two drawings.
For example, a hypothetical note might say that an arm outline has changed and that its connection detail still requires review. That is more useful than “updated drawing.” It describes the changed area without inventing a tolerance, fixing specification or engineering conclusion.
Revision callouts can help locate an affected area. Onshape's revision-table instructions show how revision records and drawing callouts can be connected. Treat that as one implementation example. Whatever system the team uses, make sure the description remains available in the actual files received by the workshop.
Do not let visual emphasis become the decision itself. A highlighted detail tells a reader where to look; it does not establish acceptance. If changing the detail also changes a neighbouring component or interface, name that question separately. The component-substitution guide addresses that review boundary in more depth.
Keep samples and attachments connected
Furniture development is not contained in one drawing. A finish reference, upholstery selection, component list and physical sample can each answer a different question. They become difficult to use when their relationship is implied rather than recorded.
Name the attachments that belong to the release packet and give each an identifiable reference. If the team is using a physical sample, record which sample it is and what decision it represents. A finish sample might settle an appearance question without approving a revised joint or the complete furniture assembly.
Photographs are useful for locating a sample and recording a visible observation. They should not silently replace the agreed physical reference or a dimensional drawing. Equally, a sample approval email should not be stretched beyond the feature and purpose that were actually reviewed.
If two records disagree, make the discrepancy visible. Ask the responsible reviewer to identify the controlling reference and issue the correction. Avoid deciding informally that the photograph, the newest email or the most polished drawing must take priority. For colour and surface decisions, the finish-specification guide provides a complementary way to define the reference being discussed.
Use a release record that travels with the files
The following record is an editorial working aid. It is deliberately short enough to sit beside a drawing packet. It does not replace a company's document-control process, contract or technical review. Adapt the fields to the actual project and keep decisions attributable.
| Field | Record before the handover |
|---|---|
| Furniture identity | Model, variant and relevant component or assembly |
| Drawing set | Drawing numbers, revisions and included sheets |
| Intended use | What the recipient is being asked to make or review |
| Change summary | Affected area and the reason for this issue |
| Linked references | Sample identity and applicable attachment versions |
| Open decisions | Unresolved questions, named owners and any limits on use |
| Release decision | Responsible person, decision date and exact released packet |
| Distribution | Recipients and how superseded working copies are identified |
Read the record from the recipient's position. Could someone who missed the design meeting tell which object it covers? Could they distinguish a discussion copy from the packet intended for work? Could they identify a question that remains open without searching through a private message thread?
A blank field is not automatically a failure. It may be genuinely inapplicable. Say so where that helps, rather than filling every cell with reassuring but vague language. The value of the record lies in an explicit decision, not in how complete the form appears.
Replace working copies without erasing the history
Once a new reference is released, consider where the previous one is still being used. It may be in a shared folder, on a printed workshop sheet or attached to a procurement message. Updating one central file does not explain to every recipient what has changed.
Use an agreed way to distinguish superseded copies from the current working reference. Preserve the history the project needs, but make the status clear enough that an old copy is not mistaken for a new instruction. This is a workflow recommendation, not a prescribed retention period or a particular software procedure.
Send the new packet with its release record and an intelligible change summary. Ask relevant recipients to confirm that they can identify the correct reference. Where work has already started, route the difference to the responsible decision-maker before assuming the change applies retrospectively.
There may be a legitimate reason to keep different references for different purposes. A prototype record and a later production record need not be identical. The important requirement for this proposed workflow is to name the purpose and scope, so a useful historical document does not become an accidental current instruction.
Release is not proof of performance
A release decision answers a document-control question: which reference has the team authorised for the stated purpose? It does not, by itself, demonstrate that an outdoor furniture assembly is suitable for every location, use or performance requirement.
SATRA's furniture test-selection resource treats furniture assessment as a separate technical activity, with distinctions between product types and materials or components. That boundary matters here. A revision record does not determine which assessment is appropriate or whether existing evidence applies to a changed design. Those questions belong with the competent reviewer and the actual project requirements.
Keep any testing, inspection or other technical evidence linked to the configuration it describes. If a release includes a change, ask whether that change affects the scope of the evidence being relied upon. Do not invent a universal rule that every change requires the same response, or that a familiar appearance means nothing needs reviewing.
The useful handover separates what is settled from what remains to be established. That clarity helps a workshop proceed with the agreed work while keeping unresolved matters visible to the people responsible for them.
Bring a clear reference into the conversation
Before the next development discussion, assemble the current drawing packet, identify its intended use and list the questions that still need a decision. If the discussion concerns a revision, bring the previous reference too, with a concise account of the difference.
Talk with the workshop about the form, profile and interfaces being developed. For a first comparison of the four Sumparwood finishes, request the Sample Box. Physical material references support colour and surface discussion; they are not production release, assembly approval or performance certification.
One clear packet will not remove every question. It gives the team a common place to answer them, and a traceable reference when the work moves forward.