Getting started with ProductTrust
ProductTrust connects a governed product revision to the people, requirements, supplier responses and evidence needed to make a review decision. Start by establishing the exact product identity. The related guides show how to collect and review a supplier response and prepare a technical-file version.
The Odoo 20.0 Community suite contains 22 shipping addons. The suite brings their capabilities together; the menus available to you depend on installed components, company access and assigned roles. This guide starts with Products & Identity and assumes an administrator has installed the suite or the required components.
Choose the right responsibility
| Role | Responsibility in these guides |
|---|---|
| ProductTrust User | Read permitted records. For ordinary users, identity access can require a current assignment to the exact subject. |
| ProductTrust Compliance Manager | Maintain product identity and configuration; prepare supplier requests and technical files within permitted companies. |
| ProductTrust Qualified Reviewer | Perform the applicable review decisions after their prerequisites are met. This is a separate role from Compliance Manager. |
| ProductTrust Publisher | Request publication of eligible, approved passport versions. This separate role is outside these setup and preparation steps. |
A role does not remove company boundaries or workflow checks. Some operations also require a current assignment for the exact subject and purpose. In Products & Identity → Actor Assignments, a manager can inspect the principal, subject, role, access class, purpose and validity dates. Each assignment identifies one principal and has a finite expiry. Ask your administrator to resolve a missing or expired assignment before continuing a restricted action.
For the creation steps below, use a Compliance Manager account in the intended company. Have a product name, a unique family code, a unique model code, a revision label and the intended countries available. If linking a commercial product or variant, that native Odoo record must already be accessible.
Establish your first governed product
- Open ProductTrust → Products & Identity → Product Families. Search for the family before creating another one. If it is new, choose New, enter its name and code, confirm the company and save. Use Native Products to associate existing Odoo product templates when useful. Family codes are unique within a company and are stored in uppercase.
- Open Products & Identity → Market Scopes. Reuse a suitable scope or create one with a name, code and countries. Enter validity dates when applicable; the end cannot precede the start. Use a scope that reflects the intended markets for this product revision.
- Open Products & Identity → Product Models and choose New. Enter a name and unique model code, select the family, and enter the manufacturer-controlled Model Version. For example, a fictional FieldLink S1 revision B can be a separate model within the FieldLink family. Select the applicable market scopes.
- If the model corresponds to a native Odoo product, select its template. If it is variant-specific, select a variant belonging to that template. Save. The family must be in the same company; a variant requires its matching template.
- Reopen the family and select Governed Models. Confirm that the new model is listed, then open it and check the version label, native-product link and markets. ProductTrust supplies the Graph Subject and Public ID automatically; users do not enter or replace those identifiers.
- If operator responsibilities are part of the next task, open Products & Identity → Economic Operators. Reuse or create the relevant operator with a name, native contact and role, such as manufacturer or importer. Record the basis and limitations of any verification status according to your organization's review process. An operator label alone does not establish a legal appointment or certification.
Result: colleagues can find one governed revision under its family, identify the associated native product and intended markets, and use that exact record in subsequent requests and technical files. Native Odoo products continue to hold the commercial product information.
Choose the next daily task
| You need to… | Start here | Check before moving on |
|---|---|---|
| Obtain missing supplier information | Suppliers → Requests | Exact recipient, due date, subject and requirement lines |
| Inspect an uploaded report and its review state | Evidence → Documents | Exact document version, processing outcome and independent review |
| Assemble a product's review package | Technical Files → Technical Files | Product revision, markets, owner, intended use and versioned evidence |
| Follow up a pending decision | The relevant record's chatter and activities | Responsible person and due date; a task assignment does not approve the underlying record |
Correct common setup problems
If a record or menu is missing, first confirm the installed component, selected companies and role. For a restricted identity record, a manager should check the exact subject assignment and its dates. Do not assume a visible menu grants access to every record.
If a code is rejected as a duplicate, search for the existing family or model in that company. Use a distinct code for a genuinely separate governed revision. Do not create duplicate identities merely to work around access restrictions.
If the wrong company was used, have the manager resolve the record in the correct company: a saved governed identity cannot simply be moved to another company. Stable identity records are archived when no longer used; deletion is blocked.
Scope and example limits
The optional FieldLink S1 story uses fictional Northstar Products and Meridian Components. Its records deliberately include unfinished work. A draft request, upload-pending evidence, planned test or draft technical file is a starting point for work, not a completed review. The story shortcuts appear only when the optional demonstration data is available.
These instructions were reviewed against the shipping Odoo 20.0 source on 29 October 2026, including core models, forms, menus and access controls, the suite manifest and the FieldLink demonstration guide. The workflow was not rerun for this article. Approval within ProductTrust, legal compliance, certification and external publication are separate outcomes; follow the applicable workflow and your organization's responsibilities for each.
More workflows
Analyze an engineering change for review.
Review evidence assertions and approve an exact document version.