Every automated write gets its own logged entry — which field, what value, tied to which approval event, at what time. That's the short answer to how you automate QMS registers without losing the ability to answer an auditor's question: who changed this, and when, and why.
Hand-maintained registers rarely have a good answer to that question. A cell in a spreadsheet changes, and unless someone happened to note it elsewhere, the history of that change is gone the moment it's overwritten. An activity log is what closes that gap, and it's worth understanding exactly how it works, because "we log everything" means very different things depending on what's actually being logged and when.
What gets logged, and when
In the automation we build, nothing gets written to a register until a human decision has already been made and recorded. Once that happens, the system writes eight specific fields that a document controller previously had to retype by hand: revision number, effective date, amendment-record entry, master document list row, change-register entry, the year-keyed request number, page count, and the calculated retention or disposal-due date.
Each of those eight writes is logged individually, not as one bundled "document updated" event, but as eight separate, traceable entries. That distinction matters more than it sounds. A single bundled log entry tells you a document changed. Eight individual entries tell you exactly which field changed, what the new value was, and which approval event triggered it. If a number looks wrong six months later, you're not reconstructing what happened from memory, you're reading it directly.
| Logging approach | What you can answer later |
|---|---|
| No log (manual retyping) | Nothing — the only record is whatever's currently in the cell |
| Bundled log ("document updated") | That something changed, roughly when |
| Per-field activity log (what we build) | Which exact field changed, to what value, tied to which approval event, at what timestamp |
Why per-field logging matters more than it sounds
Most of the value of an activity log shows up months or years after the write happens, when someone is trying to answer a specific question rather than browse a general history. A few examples of what per-field logging actually lets you trace:
- A retention date looks off during an internal audit. The log shows exactly when it was calculated, from which approval event, without anyone needing to recall the specific revision cycle.
- A distribution matrix entry is questioned — did department X actually get notified of this revision? The log shows the write, the timestamp, and the triggering approval, rather than relying on someone's memory of sending an email.
- Two people disagree about which revision number is correct. The log resolves it, because the number was written once, automatically, from a single source of truth, and every write is timestamped.
None of this requires interpreting anything. The log doesn't summarize or judge — it records what was written, when, and as a consequence of which recorded human decision. That's a narrower job than a full audit-management platform does, and that's deliberate: the log's only purpose is traceability of the clerical layer, not a substitute for the human decision gates that sit above it.
Idempotency: the other half of the traceability story
An activity log that's accurate but duplicated isn't much better than no log at all — if the same approval event somehow triggers the write twice, you now have two register entries claiming to be the authoritative record. This is why the workflow we build is idempotency-keyed: replaying the same approved event doesn't create a duplicate entry in the register or a duplicate log line.
This matters in practice more than it sounds like it should. Automations retry. Network calls time out and get resent. A person might resubmit an approval by accident. Without idempotency, any of those ordinary events could quietly double a register row, and now your master document list has two conflicting "current" revisions with no obvious way to tell which one is real. With it, the same event can fire ten times and the register still shows exactly one entry, because the system recognizes it's already processed that specific approval.
Why automate QMS registers instead of a hand-maintained one
A document controller retyping fields into a spreadsheet is, functionally, doing the same job the automation does: writing the same eight fields into the same registers. The difference is what happens after the write.
A spreadsheet cell has no memory of its own history unless someone builds one manually — a separate change log, updated by hand, which is itself just another spreadsheet a person has to remember to keep accurate. Every additional manual log is another place transcription errors can creep in, and another thing that can silently fall out of date the week someone is busy.
An automated write generates its log entry as a side effect of the write itself. There's no separate step to forget, because logging isn't a task someone does — it's a property of how the system executes. That's the practical case for why systems that automate QMS register updates tend to hold up better under audit scrutiny than spreadsheet-based ones: not because software is inherently more trustworthy, but because the log can't fall behind the data it's describing.
What the activity log doesn't do
It's worth being direct about the limits here too. The activity log records what the automation wrote and when — it doesn't evaluate whether the underlying document change was correct, and it doesn't replace your reviewer or approver sign-off as the record of the actual decision. Those human decisions happen upstream, on the paper form or in whatever system you already use to capture approvals; the activity log picks up from there and traces only the clerical execution that follows. If you want the full picture of what those eight written fields actually are, that's worth reading alongside this one.
FAQ
Does the activity log capture who approved the document, not just what was written?
The log ties each write to the specific approval event that triggered it. The record of who reviewed and who approved lives in your existing sign-off process — paper form, e-signature tool, or whatever your SOP specifies — and the activity log references that event rather than duplicating it.
Can activity log entries be edited or deleted after the fact?
No. The log is a record of what happened, not an editable field. If a downstream correction is needed, it happens through a new, separately logged action; the original entry stays intact.
Does idempotency mean the system silently ignores retries?
It means a retry of the same already-processed event doesn't create a duplicate register entry or log line. The system recognizes the event as already handled rather than treating it as new.
Will an auditor accept a system-generated log instead of a manually signed register?
An activity log that ties every write to an independently documented human approval event is generally easier to verify than a hand-maintained register, because there's no gap between when a change happened and when it was recorded.
Does this work with our existing QMS software, or does it replace it?
It depends on how your document control runs today. The activity log can sit underneath a spreadsheet-based register or alongside a QMS platform — the point is traceability of the automated writes themselves, not replacing tools that already work for you.
If you want to see how this traces against your own registers rather than a description of someone else's, book a workflow walkthrough and bring a recent revision cycle. 1% EVO builds these systems to automate QMS register updates without losing the paper trail an audit actually needs.