What is Revision Control in PLM?

What is Revision Control?

Revision control is the discipline of managing changes to product data — CAD models, drawings, specifications, BOMs, test procedures — in a way that is intentional, approved, and permanently auditable. The word "control" is doing real work here. It does not mean tracking changes passively, the way a wiki logs edits. It means that a released document cannot be changed without a formal process, that every change is linked to a stated reason, and that the history of every revision is preserved indefinitely.

The foundational distinction in revision control is between a version and a revision. A version is a work-in-progress snapshot — the drawing as it exists after Tuesday's design session, before the review meeting on Thursday. Versions are fluid; they are expected to change. A revision is a formally released snapshot that has been reviewed, approved, and locked. Revision A of a drawing is a specific, immutable artifact. When manufacturing needs to know what tolerance to hold on a bore diameter, they pull the latest released revision — not the latest version, not the file the designer saved yesterday.

PLM systems enforce this distinction through lifecycle state machines. A drawing in Draft state can be freely edited. A drawing in Released state is protected against modification at the system level. To change it, an engineer must initiate an Engineering Change Request, obtain approvals, make the changes in a new working version, go through another review cycle, and release that new version — which then becomes the next revision (Revision B). The system logs every state transition: who approved, when, and under which change order. This is what a PLM audit trail looks like, and it is materially different from a folder of files with dates in their names.

Why Revision Control Matters in PLM

Manufacturing builds from drawings and models. If the drawing manufacturing is using is not the current released revision — if it was superseded six months ago and nobody told the shop floor — then the part being built is wrong. It may be wrong by a dimension, a material spec, or a surface finish requirement. The physical parts may look identical to the naked eye. The defect may not manifest until the product is in the field. By then the cost of the error — warranty, recall, regulatory action — far exceeds what a functioning revision control process would have cost.

This is not a hypothetical risk. Studies from manufacturing organizations consistently identify configuration and revision control failures as a leading root cause of non-conformances and rework. The problem is especially acute during product launches, when engineering is releasing rapid changes and manufacturing is simultaneously trying to ramp production. Without disciplined revision control, the change rate exceeds the organization's ability to communicate it, and the shop floor ends up building against whatever version was current when they last checked.

Revision control also matters for regulatory compliance. Aerospace, medical device, automotive safety, and pharmaceutical manufacturers operate under regulatory frameworks — AS9100, ISO 13485, IATF 16949, 21 CFR Part 11 — that require demonstrated control over product design records. Auditors ask two questions: What was the design specification at the time the product was released? Can you demonstrate that manufacturing built to that specification? Answering both requires a functioning revision control system with an intact audit trail.

Common Use Cases

• Drawing release management: Engineering releases a new drawing revision through PLM approval workflow, automatically notifying manufacturing and updating the associated BOM revision reference. No manual communication required; the system drives the notification.
• Supplier data control: A supplier-delivered component drawing received as a PDF is imported into PLM and assigned a revision. When the supplier updates the drawing, PLM captures the new revision and routes it for review before it replaces the prior version in the BOM.
• Design history file maintenance: For medical devices, the PLM revision control system serves as the Design History File — the regulatory-required record of every document and change associated with the device design, from concept through production release.

Related Concepts

• Configuration Management in PLM — revision control is a subset of configuration management; configuration management also covers variant and effectivity control
• Engineering Change Management in PLM — the change order process that governs how new revisions are created and approved
• What is MBOM? — manufacturing BOMs reference specific part revisions; revision control failures propagate directly into BOM integrity problems

Frequently Asked Questions

What is the difference between a version and a revision?

A version is a work-in-progress snapshot of a document that is still being developed and can be freely modified. A revision is a formally released snapshot that has been reviewed, approved, and locked — it cannot be changed without initiating a formal engineering change process. PLM systems typically display both, but only revisions are used as the basis for manufacturing, procurement, and regulatory submissions.

How does PLM enforce revision control?

PLM systems enforce revision control through lifecycle state machines. A document moves through defined states — Draft, Under Review, Released, Obsolete — and each state transition requires specific approvals. Once a document is in the Released state, the system prevents modification. To change it, a user must initiate an ECR or ECO, which creates a new working version that will eventually become the next formal revision.

What happens when revision control breaks down?

When revision control breaks down, manufacturing teams build from superseded drawings, suppliers quote against outdated specs, and service technicians install incorrect replacement parts. The failure typically becomes visible only after a production defect or field failure — by which point multiple units may have been built incorrectly. Reconciling which units were affected and what the correct configuration should have been requires a forensic investigation that consumes significant engineering resources.