Why your template fix didn't propagate — and why that's the right design

Three weeks ago, a junior engineer on my team asked the most predictable question I hear in any eQMS: "I fixed the template — why didn't the change show up on my open records?"

She'd corrected a field label in our design history file template. The new wording was clearer, scannable, would have saved her twenty minutes on the next review. She fixed it once, expected it everywhere. Standard expectation. The records she'd already opened still showed the old label.

In Greenlight Guru. In MasterControl. In every QMS I've touched since 2011. The behaviour is consistent across the category, and qmsWrapper does the same thing.

The design choice hiding behind your "bug"

Here's what took me a while to internalise: this isn't a bug. It's the system working as intended. When you create a record against a template version, that record is bound to that version. The template can be revised, the record cannot be retroactively rewritten. ISO 13485 §7.5 and 21 CFR 820.40 both live in that space — controlled documents, record integrity, traceability of changes.

In qmsWrapper this is explicit. The Document module keeps a version history per record. Existing DHF entries, risk files, CAPA records — they all stay on the version they were created under. The fixed template shows up correctly for new records. Old records keep their original content with a version stamp you can audit against.

That's the right call for a notified body audit. It's still a bad afternoon for whoever thought a template edit would propagate.

What the engineer actually needs

Most of the "why didn't it propagate" tickets I've filed over fourteen years come down to one of three things:

• The user assumed fix-once-fix-everywhere. That's spreadsheet thinking. A QMS record isn't a cell formula.
• The user wants to apply the cleaner wording to in-flight records without losing the audit trail of what was reviewed and approved originally.
• The user is about to reissue or migrate the record anyway and just wants to know if they should pull from the old template or the new one.

In all three cases, the answer is the same: the existing record is what was approved. Don't touch it. Create a new revision if the change is material. If it's cosmetic, leave it.

The workflow that has actually saved me

When a template change is going to affect open work, I do this now:

1. Flag the change in the change control record itself. The template revision note captures what was corrected and why.
2. Run a quick search in the Document module for records still on the old version. Filter on template version makes this a two-minute job, not an archaeology project.
3. For each open record, decide explicitly:
   • Is it a draft? It can be reissued onto the new template.
   • Is it approved but not yet effective? Same — reissue and re-route through the workflow.
   • Is it effective and in use? Leave it. Document the template version it was created under. Move on.
4. For closed records, do nothing. They're historical. They're done.

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

Why I'm still thinking about this

The behaviour is defensible. I'd argue it has to be defensible — anything else breaks the version-of-record integrity that a notified body audit leans on. The part I keep chewing on is the user experience side.

When a junior engineer hits this for the first time, the system gives them no nudge. No banner saying "this template has been revised; existing records remain on version X." No link to the records that will need attention. The knowledge is in the Document module if you go looking, but the friction of finding it lands on whoever noticed the inconsistency first.

I've watched that friction turn into a Slack thread, then a ticket, then a CAPA investigation into a "template inconsistency" that was never actually an inconsistency. Just a gap between how the team thought the system worked and how it does work.

Open question

For anyone running a QMS rollout — how do you onboard new engineers to the "template versions are bound to records" model before they hit it the hard way? Is there documentation, training, or in-product nudging you've seen work? Or is the bad-afternoon experience just part of the rite of passage?

Disclosure: I work on qmsWrapper.