Analyze an engineering change and hand it to review

Use an engineering change to record what is proposed, which product or component it concerns, and which related subjects need attention. This workflow takes a saved proposal through Draft → Impact Analyzed → Review. Its result is a review handoff with a recorded impact analysis.

A ProductTrust Compliance Manager checks the prepared proposal, runs Analyze Impact and selects Submit for Review. A ProductTrust Qualified Reviewer assesses the handoff. The reviewer must be a different user from the proposal's recorded proposer when preparing or making its approval or rejection decision.

Before you begin

The ProductTrust Change Control component must be installed. Work in the intended company and use active, accessible product or component subjects from that company. Confirm the governed revision using Getting started with ProductTrust. Check any supplier information through Supplier requests before describing it as established fact.

Start with a saved Draft that already contains valid proposed change lines. Adding or changing proposed lines through a saved proposal is outside this guide because its update rules restrict those edits. A new-proposal creation flow was not verified. If no suitable prepared Draft exists, this workflow cannot start. Check the current and proposed values, reason code and explanation against the supporting product information. Also identify the subject relationships that should connect the component to the product, operator or other affected records. Impact analysis follows recorded relationships; it cannot discover a relationship that has not been entered.

Ordinary ProductTrust users can read a change only within their permitted company and record scope—for example, through a current assignment to the change's subject for Read Engineering Changes for Subject. A visible menu alone does not grant every record or workflow action.

Inspect the prepared proposal

1. Open ProductTrust → Change Control → Engineering Changes and find the saved proposal. Confirm Draft, the company, recorded proposer and exact product revision described in the proposal. The company and proposer are read-only. If the prepared record is missing or belongs to the wrong company, stop before analysis.
2. Open Proposed Changes and inspect every line's Target Subject, category, Reason Code and Rationale. The target must be active and belong to the change's company. The reason uses a stable lowercase code, such as connector_revision; the rationale explains why the change is needed.
3. Inspect the line's Before Snapshot and Proposed Snapshot. The separate Change Control → Change Lines menu provides read-only inspection of these details. Snapshots are JSON objects containing current and proposed facts, with accepted field names depending on the category. For a Component line, component_code, part_number and revision are supported examples. The synthetic exercise below shows the format. The application supplies the recorded digests.
4. Check that every intended target is represented, the snapshots accurately distinguish current facts from the proposal, and the rationale explains the change. At least one line is required. Do not proceed with incomplete or inaccurate preparation.
5. Check the relevant Products & Identity → Subject Relations with the person responsible for the product graph. Confirm their company, active status and validity dates. Resolve proposal or relationship questions before analysis.

Checkpoint: the existing proposal and its lines are ready to freeze for analysis. After Analyze Impact succeeds, the proposal moves out of Draft and those lines are no longer editable. This workflow has no reset-to-Draft action or re-analysis action for an already analyzed proposal.

Analyze and inspect the affected subjects

6. On the prepared Draft, select Analyze Impact. On success, confirm Impact Analyzed and open Impact Analysis. Inspect the current analysis, change revision, completion time, Relation Effective Date, result and counts. The relation effective date uses the server's date when the analysis runs.
7. Open the current analysis and its Affected Subjects page. For each row, check the originating change line, root subject, affected subject, depth and impact class. A direct impact is one relationship away; an indirect impact is farther along a relationship path. Open a row to inspect the Relation Path when you need to understand why it appears. The Change Control → Impact Analyses and Affected Subjects menus also provide read-only inspection.
8. Compare the result with your knowledge of the product change. Identify which affected records need a specialist's assessment—for example, a connector change may prompt checks of product configuration, instructions and test planning. These are follow-up decisions for the team; appearing in the graph does not prove a physical incompatibility or create a test, supplier request or technical-file revision automatically.

Result: the proposal has a completed analysis tied to its revision and line contents. The analysis retains the paths found and a recorded fingerprint of the relationships considered. Its affected count is a path count, not necessarily a count of distinct subjects: the same subject can appear for more than one proposed line.

A result of Complete — No Related Subjects means no related subjects were found within that analysis. Check the recorded relationships and their validity before treating that as a useful handoff. It does not establish that the proposed change has no business, safety or regulatory consequences.

Submit the review handoff

9. Return to the engineering change and select Submit for Review. The manager action requires Impact Analyzed and a complete current analysis matching the proposal's revision and line contents. Confirm the state changes to Review.
10. Have the separate Qualified Reviewer open Change Control → Review Required, select the proposal, and inspect Proposed Changes, Impact Analysis and Review & Decisions. Agree which additional product or evidence checks are needed before a decision. The queue contains proposals in Review; it does not prove that someone has read or approved them.

Result: the proposal is available for qualified review with its exact proposed values and impact evidence. This guide ends at that handoff. A later Approve or Reject decision requires a nonempty reviewer rationale and a current matching analysis; the proposer cannot prepare or make their own decision. Approval, scheduling, application, verification and closure remain separate stages.

For follow-up material, use Prepare a technical-file version to assemble the relevant requirements, source records and governed evidence. An engineering-change analysis does not approve an evidence document or publish a passport.

Synthetic exercise: a connector revision

Use a training company with a fictional connector subject and its recorded relationship to a fictional product model. These example values are illustrative; they are not a claim about the installed FieldLink records or a completed compatibility test.

1. Use an existing prepared, saved Draft named Training — connector revision B. The exercise requires it to contain a Component line targeting the training connector, Reason Code connector_revision, and a rationale explaining that a proposed part change needs product-impact review.

2. Inspect its Before Snapshot, which should contain these fictional facts:

   {"component_code":"TRAIN-CONN","part_number":"TRAIN-100-A","revision":"A"}

3. Inspect its Proposed Snapshot:

   {"component_code":"TRAIN-CONN","part_number":"TRAIN-100-B","revision":"B"}

4. As a Compliance Manager, finish the checks above and select Analyze Impact. If the training connector has an active, currently valid relationship to the product model, inspect that model's affected-subject row and path. If the result is empty, explain the missing relationship or scope to the trainer rather than inventing an impact result.

5. Select Submit for Review and have a different Qualified Reviewer locate it in Review Required. Stop in Review. The exercise's expected outcome is a reviewable proposal, not approval or an applied product change.

When the workflow stops

What you see	What to check next
A menu, record or button is missing	Check the installed component, company access, role and any subject assignment. Analyze and submit require Compliance Manager; the review queue requires Qualified Reviewer.
A proposed target is rejected	Confirm the subject is active, accessible and belongs to the proposal's company.
Invalid snapshot or reason code	Return the prepared proposal to its owner. The format requires valid JSON objects, category-supported field names and a lowercase reason code. Snapshots accept integers and text but reject decimal JSON numbers; an agreed decimal value can be represented as text. Free-form explanations belong in Rationale.
Impact bounds exceeded	Ask the product-data owner to review the proposal's scope and relationships. The normal action is bounded; do not omit relevant changes merely to force a passing analysis.
Current analysis is missing, incomplete or stale	Stop the handoff. Check the displayed revision and current analysis with the administrator. Submission checks proposal consistency; there is no supported reset or re-analysis button after this state transition.
The proposal needs correction after analysis	Preserve its history and stop this handoff. A corrected proposal requires a separate valid Draft; preparing it is outside this guide. Engineering changes cannot be copied or deleted, and their analyzed lines cannot be overwritten.
The proposer cannot enter a review rationale	Use the separate Qualified Reviewer account responsible for the decision. Holding both roles does not remove the proposer/reviewer separation.

Interpret the limits correctly

Analysis considers accessible, active, same-company subject relations valid on its recorded effective date. It traverses supported relations in both directions and retains one shortest path for each proposed line and affected subject. The normal action permits up to 16 proposed roots and follows relationships up to six levels deep; additional subject, relation and path limits apply. The Bounds tab records the limits used. “Complete” means completion within those limits, not coverage of every possible consequence.

The recorded analysis is a snapshot. Submission checks that it still matches the proposal; it does not rerun the relationship graph or compare the proposed values with live product data. If relationships or real product facts have changed since analysis, bring that to the reviewer before proceeding. A new current proposal may be needed; its preparation is outside this guide.

This guide was reviewed against the Odoo 20.0 Community change-control source on 29 October 2026. The earlier fictional FieldLink narrative includes an impact-analysis and review-submission handoff, but no new UI session was run for this article. Source review does not establish runtime acceptance, legal certification, completed engineering work or external publication.