Changed the Template but It Won't Take Effect? Unpacking the Design Logic Behind QMS Record Version Binding

An Engineer's Puzzle: I Changed the Template—Why Didn't the Old Records Change?

Three weeks ago, a junior engineer on my team asked me a classic question that I've heard in every eQMS system: "I fixed the template—why does the record I open still show the old version?"

She had corrected a field label in the Design History File template. The new wording was clearer, more readable, and would save her twenty minutes on the next review. She changed it once and expected it to sync everywhere. That's a natural expectation. But the records she had already opened still displayed the old label.

In Greenlight Guru, MasterControl, and every QMS I've worked with since 2011, the behavior is consistent—and qmsWrapper is no exception.

This Isn't a Bug—It's Deliberate Design

It took me a while to truly understand: this isn't a bug, it's the system working as intended. When you create a record based on a template version, that record is bound to that version. Templates can be revised, but records cannot be retroactively rewritten. ISO 13485 §7.5 and 21 CFR 820.40 both touch on this area—controlled documents, record integrity, change traceability.

In qmsWrapper, this is explicit. The document module maintains version history for every record. Existing DHF entries, risk files, CAPA records—they all stay on the version they were created under. The fixed template displays correctly for new records, while old records retain their original content with an auditable version stamp.

For notified body audits, this is the right choice. But for someone who assumed editing a template would automatically propagate, it's still a bad afternoon.

Regulatory Context: ISO 13485 §7.5 and 21 CFR 820.40

ISO 13485 §7.5, Production and Service Provision, requires organizations to plan and control production and service provision processes, including controlled management of changes to approved documents—ensuring changes are reviewed and approved before implementation. 21 CFR 820.40 is the document control clause in the U.S. FDA quality system regulation, which explicitly distinguishes between "document changes" and "records": documents (such as templates, procedures, specifications) can be revised, but records are evidence of completed activities and must not be retroactively altered—they must retain their original state and traceable modification history. The shared logic is: templates are "controlled documents" that can be updated as processes iterate; records are "evidentiary documents" whose value lies in faithfully reflecting the actions taken at the time. If a system allowed template changes to automatically write back to historical records, it would break the integrity of this evidence chain, making it impossible during an audit to prove what was actually reviewed and approved at the time. This is precisely the regulatory root cause behind why all compliant eQMS platforms design version binding to prevent retroactive write-back.

What Users Actually Need

In fourteen years, most of the "why didn't it propagate" tickets I've filed boil down to one of three situations:

• The user assumed "change it once and it applies everywhere." This is spreadsheet thinking. QMS records aren't cell formulas.
• The user wants to apply clearer wording to in-progress records without losing the audit trail of what was originally reviewed and approved.
• The user is about to re-release or migrate the record and just wants to know whether to pull from the old template or the new one.

In all three cases, the answer is the same: the existing record is the approved content. Don't touch it. If the change is significant, create a new revision. If it's just cosmetic, leave it alone.

What Is "Spreadsheet Thinking," and Why Doesn't It Apply to QMS?

"Spreadsheet thinking" comes from everyday Excel habits: modify a formula or value in one cell, and everywhere that references it recalculates automatically. This "edit once, applies globally" intuition is harmful in QMS contexts because QMS records aren't calculated fields—they're legal evidence with approval signatures and timestamps. Once a DHF entry or CAPA record is approved and effective, it represents the organization's formal decision at a specific point in time. If a user's edit automatically propagated to approved records, it would amount to tampering with evidence without re-running the approval process—which would be treated as a serious nonconformity in a notified body audit. That's why QMS systems often deliberately sacrifice "convenience" in user experience in exchange for "auditability." Understanding this trade-off is a key step for engineers transitioning from tool thinking to compliance thinking.

The Workflow That Actually Saved Me

When a template change will affect in-progress work, here's what I do now:

1. Flag the change in a change control record. The template revision description documents what was corrected and why.
2. Quickly search the document module for records still using the old version. Filter by template version—this takes two minutes, not an archaeology project.
3. Decide explicitly for each in-progress record:
   • Is it a draft? It can be re-released onto the new template.
   • Approved but not yet effective? Same—re-release and re-run the workflow.
   • Effective and in use? Leave it. Document the template version it was created under. Move on.
4. For closed records, do nothing. They're history and they're done.

The last step is one teams often skip. Closed records exist precisely so the audit trail matches what actually happened on that day.

The User Experience Gap

This behavior is justified. I believe it has to be—any other approach would undermine the record version integrity that notified body audits depend on. But what I keep thinking about is the user experience side.

When a junior engineer encounters this for the first time, the system gives no hint. No banner saying "This template has been revised; existing records remain on version X." No link pointing to records that need attention. The knowledge is there in the document module if you go looking, but the friction of discovering it falls on the first person to notice the inconsistency.

I've seen this friction turn into a Slack discussion, then a ticket, then a CAPA investigation into "template inconsistency"—when that "inconsistency" was never really an inconsistency. Just a gap between how the team thought the system worked and how it actually works.

Why "Template Inconsistency" Can Trigger a CAPA Investigation

CAPA (Corrective and Preventive Action) is the core mechanism in a quality system for addressing nonconformities. When a team discovers the same field label differs across records, the first instinct is often to suspect a data integrity problem in the system, which then triggers a CAPA investigation—because record integrity directly relates to product safety and regulatory compliance. However, if the investigation finds that this "inconsistency" is actually the natural result of template version iteration, then the entire CAPA process is a waste: it consumes quality department time, creates additional documentation burden, and solves no real defect. These "false positive CAPAs" triggered by experience gaps are especially common in small and mid-sized medical device companies, and they're a direct driver for eQMS vendors to improve in-product hints (such as version difference banners and pending lists of old-version records).

A Question for QMS Implementers

For anyone in the middle of a QMS deployment—how do you get new engineers to understand the "template version bound to record" model before they run into this problem? Is there documentation, training, or in-product hint that you've seen work? Or is that bad afternoon simply a rite of passage?

Disclosure: I work at qmsWrapper.

One-line Summary

QMS templates not updating old records is compliant design; engineers need to understand the record version binding model.

Paragraph Summary

The article starts from a junior engineer's confusion, explaining why in qmsWrapper, Greenlight Guru, MasterControl, and all QMS platforms, old records still show old content after template changes. The author points out this isn't a bug, but a deliberate design to satisfy ISO 13485 §7.5 and 21 CFR 820.40 record integrity and traceability requirements: records bind to the template version at creation time, templates can be revised but records cannot be retroactively rewritten. The author summarizes three typical "why didn't it propagate" scenarios and provides a complete workflow for handling template changes—flagging change control, searching for old-version records, categorizing in-progress records, and leaving closed records as-is. The article also notes the user experience gap: the lack of system hints leads teams to misunderstand, even triggering unnecessary CAPA investigations, and invites QMS implementers to share how to help new engineers understand the version binding model in advance.