Prepare a technical-file version for review

A ProductTrust technical file gives one governed product model a stable home for its intended use, markets, responsible operators and version history. Each version brings together the exact requirements and evidence being considered. Use this guide to assemble a draft, identify unfinished work and hand it to a reviewer without losing the product revision context.

A ProductTrust Compliance Manager creates the file, allocates versions and edits the preparation data. A ProductTrust Qualified Reviewer, different from the version's creator, can approve its snapshot after all prerequisites are met. Both need access to the company and linked records. Ordinary readers may need a current assignment to the technical-file subject.

Prepare the scope

Start with an existing governed product model, appropriate market scopes and economic operators; see Getting started. Agree on intended use and operator responsibilities. Identify the person who will own the file and the separate reviewer who will assess it.

To reach approval later, you will also need reviewed or active rule-pack versions, their active requirements, approved evidence versions and accepted assertions, supported reference and source rows, approved risk assessments, reviewed declaration or marking source rows, and closed test plans. These can be outstanding work while you assemble a draft. A supplier's accepted response alone does not complete evidence review; see Supplier requests.

Create the file and its working version

1. Open ProductTrust → Technical Files → Technical Files. Search by product model first: one company can have only one stable technical-file identity for a product model. Reuse that file when it already exists.
2. For a new file, choose New, enter a name, confirm the company and exact product model, and select the owner. Write Intended Use, Operator Responsibilities and a bounded Scope Note. For example, describe what the fictional FieldLink S1 revision B is intended to do and which connector change this review covers.
3. On Exact Scope, select the applicable market scopes and economic operators. Add relevant configurations or exact subjects where appropriate. Save and recheck the scope. The stable file cannot later be reassigned to a different product model or company.
4. Select Create Successor Version. This is also the button used to allocate the first version. Open Latest Version or the new row in Version History. ProductTrust assigns the version number and creator and copies the stable file's scope and narrative into a new Draft version.
5. Check the version's product, effective dates and narrative snapshots. On Exact Scope, select the rule-pack versions and requirements for this review. Select the evidence documents, their exact governed evidence versions and the accepted assertions intended for the snapshot. Keep these selections consistent as supporting work progresses.

Result: the stable file points to a working version with explicit scope and inputs. Allocating a successor copies the file's scope and narrative; it does not automatically reproduce the preceding version's requirements, evidence, design rows, risks or tests. Review and populate those for the new version.

If a latest version is already Draft or Review, continue that version. Another successor cannot be allocated until the latest version is approved. For a different governed product model, use that model's own stable technical file.

Assemble the review material

6. On Legislation & Standards, add applicable reference rows with a name, kind, code, edition or version where relevant, and an applicability note. Link the supporting evidence documents. Record why each reference is relevant to this product scope; listing a standard does not establish that its requirements have been met.
7. On Design, BOM, Labels & Instructions, add the needed source rows. Choose the kind—such as drawing, BOM, instruction or warning—give it a useful name and source note, and link its supporting documents or assertions. An ordinary chatter attachment can support discussion, but it does not replace the governed evidence selected for approval.
8. Inspect Declarations & Marking and Risk & Tests with the responsible specialists. Declaration and marking rows hold reviewed source data, not signed legal declarations. Risk and test lists on the version are read-only summaries; use Technical Files → Risk Assessments and Technical Files → Test Plans for their respective workflows, keeping their version link correct. Record missing work and its owner before the handoff.
9. Revisit Exact Scope after adding supporting rows. Include all applicable documents and assertions used by the references, design, declarations and risks, plus the exact evidence versions used by test results. Verify the link to the selected product revision and requirements. Save the working version.

For example, FieldLink's connector drawing, compatibility report, risk controls and verification plan answer different parts of the same change. Keep each linked to revision B, and leave planned work visibly unfinished until it has been performed and reviewed.

Submit and review the snapshot

10. A Compliance Manager selects Submit for Review on the exact latest Draft version. Its state becomes Review. This action does not run the full approval checks or prove the file complete. The manager can still correct editable preparation data while the version is in Review; approved and superseded versions are frozen.
11. The separate Qualified Reviewer inspects the version and its supporting records. Use the checkpoints below before selecting Approve Snapshot. If a prerequisite fails, assign it to the responsible person, complete the underlying work and retry only when the record is ready. There is no need to allocate another version merely because a review prerequisite is unresolved.
12. On successful approval, verify Approved, the approving user and time, and Frozen Manifest. The stable file's approved and latest version links point to this version. When a successor is approved, the preceding approved version becomes Superseded and retains its place in the history.

Approval checkpoint	What the source checks
Version and reviewer	Exact latest version in Review; valid predecessor chain; reviewer differs from version creator
Scope	Selected markets and economic operators
Rules	Every selected pack is Rule Reviewed or Active; requirements are active and belong to selected packs; every selected pack has selected requirements
Governed evidence	At least one accepted assertion and approved exact evidence version; assertions use selected versions; documents, versions and assertions are coherently selected
Requirement mapping	Each selected assertion maps to selected technical-file requirements only
References and design	At least one reference and source row; references have approved evidence, and source rows have approved documents or accepted assertions
Risks and declarations	At least one linked risk assessment and one declaration/marking row; all risks are Approved, and all declaration/marking rows are Reviewed Source with approved evidence
Tests	At least one linked test plan; all linked plans are Closed and their test results are decided or superseded rather than Draft
Complete evidence selection	Evidence used by applicable lines, risks and tests is included in the version's selected snapshot inputs

Result: approval freezes a recorded version and its manifest. It does not mean every test passed: the technical-file check permits accepted, rejected or superseded test results once the other prerequisites are satisfied. The reviewer must assess the meaning of those outcomes for the product and intended use.

Continue after approval

When more work is required for the same product model, update the stable file's current scope or narrative as appropriate and allocate its next version. Populate and review the new snapshot's inputs explicitly. The existing approved version remains the approved reference while its successor is Draft or Review; it is superseded only when that successor is approved.

The optional FieldLink example deliberately stops at a draft technical file with prepared source entries and planned controls. It does not demonstrate completed evidence approval, certification or publication. Technical-file approval does not publish a passport: passport readiness and external publication have their own records, permissions and prerequisites.

This guide was reviewed on 29 October 2026 against the Odoo 20.0 technical-file models, native views, role/company rules and approval validations, with the FieldLink narrative used for illustration. It is a source-reviewed workflow guide; no current UI run or comprehensive legal-compliance assessment was performed for this article.

Related workflows

Analyze an engineering change for review.

Review evidence assertions and approve an exact document version.