Manufacturing Revisions: When Should a Proposed Change Become the Production Instruction?
Treat a proposed manufacturing change as a candidate, not an immediate edit to the instructions people are using. Before building a production app, define who may release a revision, when it takes effect and what happens to work already under way. A version number alone answers none of those questions.
This guide concerns a controlled change to a manufactured product's components or operations. It is not a certification procedure, a product-safety assessment or advice that a particular approval makes a design compliant.
Keep the experiment away from the active instruction
In its engineering change order documentation, Odoo 19 describes revisions to products and bills of materials. Proposed changes and tests remain in a revised bill and do not affect the one used in production until changes are applied. After approval, applying the revision archives the original production bill and makes the revised one the production bill.
That is a useful product example of separation, not proof that your custom application already provides it. For your brief, ask staff to demonstrate two things side by side: the instruction they must use today and the candidate someone is evaluating. Both should have an identifiable reference. A filename ending in “final” is not a release rule.
Specify the release decision, not just an approval button
The proposed workflow should show what changed and why, which product or specification it affects and who is responsible for resolving questions. Component substitutions and operation changes need enough context for the reviewer to understand the difference, rather than reading two long documents from memory.
Decide who may propose, review and release. One small team may deliberately combine roles; another may require separation. The application must reflect that explicit choice rather than assuming every editor can change production.
Approval and activation may be separate events. If your process schedules activation, show an approved revision as waiting until the actual release point. If the scheduled action fails, do not label the revision active simply because its planned date has passed. This is a requirement to commission and test, not a capability established here for every platform.
What happens to jobs that already exist?
Imagine a fictional workshop replacing a fastening component. There are unstarted jobs, a job on the bench and a completed batch. Ask which of those may adopt the revised instruction and who makes that decision. Do not silently rebind all three to the newest definition.
A practical brief can distinguish the instruction attached when a job was released from the current default used for new jobs. If an existing job must change, record an explicit disposition: continue on the old revision, hold for review, or adopt the replacement through an authorised step. Keep the prior reference and the reason.
The correct disposition depends on the real product and responsible specialists. This article does not recommend continuing an old design when a safety concern requires stopping work. The app must be able to represent the decision, not make it by a generic “use latest” rule.
Correcting a released mistake is another controlled change
If the new instruction is wrong, “undo” needs a defined meaning. Restoring a previous definition for future work does not undo physical work already performed. Preserve which revision each affected job actually used and identify the work needing follow-up.
Ask whether a withdrawn revision can still be opened for historical explanation without appearing as a valid choice for new production. Keep current selection and historical visibility separate. Also specify how staff learn that a previously printed instruction is no longer current; changing a database field does not replace paper at a workstation.
Demonstrate the boundary before accepting the feature
Use a fictional product and two clearly different specifications in the acceptance walkthrough:
- Editing the candidate leaves the active instruction unchanged.
- The reviewer can inspect the actual differences and their stated reason.
- A user without release permission cannot activate the candidate.
- Approval without activation remains distinguishable from a live revision where your process separates them.
- New work selects the intended released revision.
- Already-started work keeps its recorded instruction unless an explicit disposition changes it.
- Withdrawal preserves history and makes the affected jobs discoverable.
For a manufacturing-workflow app brief, bring blank job and change-request forms. Define the release boundary before asking for a large document-management system.
Questions to settle
Is a new document attachment enough?
Not if operators cannot tell whether it is proposed, approved or active. An attachment can carry the content while the application carries an explicit release state and reference.
Must every old job move to the latest revision?
No blanket rule fits every process. Define a reviewed transition policy, including holds and safety escalation where needed, rather than letting an edit decide retrospectively.
Does recording approval establish product compliance?
No. It records a decision in a workflow. The technical evidence, competence and regulatory obligations behind that decision require their own assessment.