Template libraries in document management systems tend to arrive with a simple on/off flag: active or inactive. It looks harmless. It is the source of a surprisingly serious claim.
“Active” is an assertion, and it is usually not true
In a document control system, “active” means approved. It means: this has been reviewed, somebody accepted it, you may rely on it.
A template set assembled from a reference library has been reviewed by nobody. It is a proposal — a good one, put together carefully, and still a proposal. Shipping seventy-five of them marked active claims a review that never happened.
That is precisely the kind of claim a compliance product exists not to make. If software is willing to say “approved” about something whose only history is that it was generated, then “approved” means nothing anywhere else in the product either.
The same is true, more sharply, of a customer’s own upload. A template uploaded thirty seconds ago that presents itself as reviewed is the one case where “who approved this?” has a real answer — and it must not be “the upload button”.
Four states, and any move between them is allowed
DnXT gives templates a lifecycle: Draft → In review → Approved → Retired.
Generated templates arrive as Draft. Customer uploads arrive as Draft. Nothing stops a Draft being used — it is a template, not a controlled record, and a team that wants to start from an unreviewed one should be allowed to. The state is shown against every template and can be filtered, so you always know what you are picking up.
One decision here is counter-intuitive: any state may follow any other, on purpose.
The usual instinct is to enforce a progression — no jumping from Approved back to Draft. But a template that was wrongly approved has to be demotable immediately, in one action, by whoever notices. A lifecycle that makes the climb-down harder than the promotion gives people a reason not to approve anything, and an approval queue full of things nobody will sign is not governance.
Moving a template takes a single button offering the move that is actually next, rather than a menu of four states. The common case is one click; the unusual case is still available.
The audit trail is the point, not a nicety
Every change of state is written to the same tamper-evident audit trail that template qualification uses.
This is what makes the lifecycle worth anything. “Approved” is an empty word unless you can show who said so and when. The status on its own is a label; the status plus a record of how it got there that can be shown to be unaltered is evidence.
One detail matters more than it looks: setting a template to the state it is already in records nothing. An audit trail that fills up with entries saying nothing happened is one people stop reading — and an audit trail people stop reading is not one.
Why not the workflow engine
DnXT has a workflow engine. Using it here was the obvious thought, and we did not.
A workflow has to be set up for each customer before any template can move at all, so every existing customer would need a configuration step before a button worked. Meanwhile this is four states with no branching, no parallel approvals and no tasks. The audit trail already provides the accountability a workflow would have been bought for.
The status is held in the same place either way, which is what makes this a safe decision rather than a shortcut: a workflow can drive it later without the library, the filters or the stored history changing. Choosing the simpler mechanism did not close the door on the richer one.
That is the test worth applying to “should this use the heavy machinery” questions generally — not “is the simple thing enough today” but “does the simple thing make the heavy thing harder later”.
Reading a template should not file a document
The second half of template governance is being able to look at one.
In many systems the only way to open a template is to create a document from it — which files a real document, with a document number, a version and a workflow behind it. Seventy-five of those, in order to read them, is not a review process. It is clutter created by the act of trying to be careful.
So DnXT offers a preview that shows exactly what creating the document would produce, and files nothing.
“Exactly” is doing real work in that sentence. The preview is produced by the same process that creates the real document — because a preview built a different way is a preview of something else, and the value of looking before you commit disappears if what you looked at came from a second process that might behave differently. It is the same reasoning behind every preview in the platform: the rehearsal has to be the performance, minus the commitment.
Migrating old values in the safe direction
A note for anyone doing something similar. Existing templates marked “active” are read as Approved on the way in.
Reading them as Draft would have been tidier and would have silently un-approved every template created before the lifecycle existed — the same false claim as the original problem, pointing the other way.
When you replace a crude flag with a proper lifecycle, the migration has to pick a direction. The right direction is the one that neither invents nor destroys a claim somebody actually made.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see template governance with a real audit trail against your own submissions.
