These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Product Lifecycle Mgmt (PLM)
- Features
- Design documents
Design documents
Keep product-linked design files, revision identities and reviewer evidence together.
OverviewDesign document register×
Product Lifecycle Mgmt (PLM) · Design documents
New
Design document register
Design documents
| Id | Product | Revision | Document type | File | Approved by | |
|---|---|---|---|---|---|---|
| IDD-851 | ITM-3769 | Rev A | DT-414 | FLE-751 | ||
| IDD-176 | ITM-6018 | Rev B | DT-866 | FLE-957 | ||
| IDD-716 | ITM-3255 | Rev C | DT-915 | FLE-360 | ||
| IDD-343 | ITM-3405 | Rev D | DT-592 | FLE-483 | ||
| IDD-293 | ITM-6450 | Rev E | DT-500 | FLE-828 |
6 of 6 records
IDD-851Design documents · DD-46529
ProductITM-3769
RevisionRev A
Document typeDT-414
FileFLE-751
What you can do
Give the reviewer the exact design basis
A drawing correction can change what production should make even when the item name stays the same. Keep the design file with its product, revision and document type, then identify the person responsible for review. Product Engineer prepares the submission; Engineering Reviewer examines the evidence before agreeing that the design basis is suitable for use. The operating team needs to understand that decision when it prepares the related production work.
The design capture action checks the linked product, responsible reviewer and revision identity against attributed source evidence. A repeated product, revision and document-type identity receives a reasoned refusal. Corrections retain the earlier submission and append attributed successor evidence. The team can then explain which file was examined and why a later correction was needed.
How the work is organized
- Product identity. Select the intended item and check its code and name against the design source. Resolve similar names before submitting a file for review. A familiar label is insufficient when it points to the wrong product.
- Document identity. Agree how revision and document type distinguish the source. Preserve the evidence behind a correction so a renamed attachment cannot conceal a changed design basis.
- Reviewer assignment. Identify the responsible person and confirm their account access. Give Engineering Reviewer the immutable submitted evidence needed to decide whether the design can proceed.
What to agree during setup
Agree the document types your team uses, revision naming and the evidence required for each review. Bring an ordinary submission and a corrected drawing so the reviewer can explain what must be checked. Decide who prepares a correction and how its reason reaches the reviewer. Rehearse these responsibilities with the people who will do the work.
Design authoring remains in your chosen CAD or document repository; any connection is a setup choice. Agree which source file is submitted and how the team retrieves it for review. Confirm how engineering communicates the reviewed revision to Production Planner before affected work is released. The planner should be able to identify the intended design basis without relying on memory or a file name alone.
Check the handoff on an actual case
Use a housing drawing whose revision changes from A to B. Submit the A document against the intended product and responsible reviewer. Ask Engineering Reviewer to inspect the file and explain the decision from its source evidence. Replay the same product, revision and document type; the duplicate refusal should retain a clear reason.
Next, follow the supported correction path. Retrieve the original submission and its attributed successor, then compare the evidence behind the correction. Product Engineer uses that reviewed context when preparing the A-to-B engineering change. Before releasing affected production, ask Production Planner to identify the design basis the team will use. Resolve any disagreement with the reviewer while the source is still available.
What your team sees
- Design document register — Find the product-linked file, revision and responsible reviewer for a design submission.
- Engineering review inbox — Inspect related change requests waiting for the revision decision.
Follow the work through
Capture and review design rehearses submission and correction. Review and implement changes carries the reviewed context into implementation. Agree permissions before the pilot.
What it keeps track of
Data model- Design documents
- Controlled design documents and approvals.
- Items
- Materials, components and finished goods.
- People
- People records for Product Lifecycle Mgmt (PLM).
- Users
- Users
Who uses it
Permissions- Product Engineer
- , Engineering Reviewer, Admin.
- Product Engineer
- Prepares evidence, Engineering Reviewer owns the design decision and Admin configures identity and access.
Set up Product Lifecycle Mgmt (PLM) your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.