In one sentence
An administrator who isn't on a restricted record's access list can still open it — but only after typing a reason and confirming with a passkey, and the record's owner is told it happened.
- The override doesn't remove the admin's reach — it records it. Admins could always read every record; now every time one does it outside the access list, there's an entry saying who, when and why.
- It's deliberate, and it's short. A typed reason of at least 10 characters, a fresh passkey confirmation, and 15 minutes of access to that one record.
- The owner finds out. An email, plus an entry in the record's own history that the owner and everyone else with access can read.
- Being on the access list skips all of it. No prompt, no email, no log entry — the override only exists for people who aren't named.
What an admin sees
Open a restricted record you're not named on and an interstitial appears in place of its content.
On a document, that's the body only — the page still shows the number, title, status, owner, dates and links. On the other modules the whole detail page is replaced, because there's no equivalent split: a non-conformance's description, root cause and investigation notes are the record, not a wrapper around it. Either way you reach the interstitial from the list, and the list still shows the record.
The panel names the person who manages access and offers two things:
- Request access — opens a pre-addressed email to the owner in your mail client, with the record in the subject line. Usually the right answer: if you need this record more than once, you should be on its access list, not breaking glass every time. (Shown when the owner has an email address on file.)
- Override and open — expands a short form with a Reason for access box.
Nothing is recorded until the last step succeeds. Backing out at any point is a non-event.
Once it succeeds, the content renders with an amber Administrator override banner pinned above it and a live countdown. The banner can't be dismissed — the failure it guards against is forgetting you're inside someone else's record.
What the override actually gets you
| Scope of one override | What it means |
|---|---|
| How long | 15 minutes, counting from the moment you confirm |
| How much | That one record. A second restricted record needs its own override, with its own reason and its own passkey confirmation |
| What unlocks | The record's content — for a document that's the body text, the file on an external document, version snapshots, diff and export; for every module it also covers attachments and the change history |
| What was never locked | Metadata — the record keeps appearing in the register, in list exports, in the review-due report, and in cross-module links |
That last row is deliberate. Listing is not access: an administrator has to be able to see that a document exists — and that it's overdue for review, or referenced by an MOC — to do the job at all. What's withheld is the reading of it.
▸Ask the Library is covered too
The AI search filters restricted records out of its source material before the model sees them, not just out of the answer. An admin who hasn't taken an override can't get a restricted document quoted back to them by asking a question instead of opening the page.
When the 15 minutes are up the page returns to the interstitial on its own. Taking a second override on the same record is fine — it's a second entry in the trail, with its own reason, which is the point.
What the record's owner sees
Two things, independently.
An email, subject "Administrator override: [record]". It names the administrator, the record, the timestamp, and the full reason they typed — not a summary of it. It links straight to the record.
The email goes to the record's owner where the module has one (a document's owner, otherwise whoever created it). It isn't sent when the owner is the person who took the override — being emailed about your own action is how notifications stop being read.
An entry in the record's history reading "Opened with administrator override", with the reason underneath. On a document that's the Change History panel in the right-hand sidebar. This entry is visible to everyone who can see the record — the owner included — not filed somewhere only administrators can reach.
Email delivery is best-effort and never blocks the override — an administrator shouldn't lose access to a record mid-incident because a mail provider is having a bad morning. If an email doesn't arrive, the history entry and the override log below still have the event.
What is not recorded
- Cancelling. Backing out of the panel, or dismissing the passkey prompt, writes nothing. A prompt someone thought better of is not an event.
- Normal access. Opening a restricted record you are named on is ordinary reading. No prompt, no email, no override entry.
If the same administrator is breaking glass on the same record over and over, the fix isn't a shorter form — it's for the owner to put them on the access list. Repeated overrides on one record are a signal that the access list is wrong, and the log is where you'd notice.
The org-wide log
Every override in the organization, across every module, is listed at Admin → Organization → Administrator Overrides — when, by whom, which record, and the stated reason. Most recent 200 events.
It is not admin-only. The page is gated on the Access audit admin permission rather than on the Admin role, so a compliance reviewer who isn't an administrator can audit overrides. That's the whole point: the people checking up on administrators shouldn't have to be one. The default Admin role has the permission; grant it on a custom role to give a reviewer the page without giving them admin rights. See Roles & permissions.
A reviewer who isn't on a restricted record's own access list still sees the event, the actor and the reason — but the record's title shows as "document you cannot view". Handing over the title on the audit page would be the same disclosure the override exists to control.
▸Opening the log is itself logged
Loading the override page writes an entry to Audit log access, like every other audit surface. Reading the log of administrators isn't invisible either.
Requirements and limits
The confirmation is a passkey, a hardware security key, or a code from your authenticator app — whichever you have to hand. Accepting the authenticator app is deliberate: break-glass is universal and not configurable, so it cannot depend on a credential an organization may have disallowed. An org that removes passkey from its allowed sign-in methods keeps full access to overrides.
It isn't configurable. There's no organization setting to switch overrides off, to loosen them, to lengthen the 15 minutes, to route them through an approver, or to exempt a particular record. Deliberately: a control an administrator can turn off isn't a control on administrators.
Signing in with a passkey counts as a recent confirmation. If you authenticated with your passkey in the last few minutes, the prompt may not appear a second time — it's still fresh. The typed reason is always required, so the override remains a deliberate act either way.
It applies to every module that has restricted records — documents, non-conformances, change requests, exemptions, FMEAs, JHAs, risks, gap analyses, meetings and audits.
What differs is how much is withheld. A document splits into metadata and a body, so its detail page still renders — the title, number, status, owner and dates — with only the content behind the override. The other modules don't split that way: a non-conformance's description, root cause and investigation notes are the record. So there the whole detail page sits behind the override, and the list is what stays visible.
Either way the record never disappears. You can always see that it exists, who owns it and what state it's in.
So — can administrators read everything?
Yes. Both the database policies and the permission model hand the Admin role unconditional reach, and in a product where the administrator configures the thing that would restrict them, that can't honestly be enforced away. Someone has to be able to recover a record whose only named reader has left the company.
What changed is accountability: there is now a record of every time an administrator used that reach, and the reason they gave for it. If the question you're being asked by an auditor, a works council, or an employee is "can the IT manager read the HR files?", the answer is "yes — and here is every time one did, with their stated reason", on a page you can open in front of them.
If the requirement is that an administrator cannot read a category of records at all, this feature doesn't provide that, and no setting in the product does. Keep those records out of the QMS.
Related
- Access control — restricting a record to specific people, roles or groups
- Roles & permissions — what the Admin role can do, and how to grant Access audit admin to a reviewer
- Passkeys — enrolling the passkey the override requires
- Record history — the per-record trail the override entry lands in
- Audit log access — the audit of the audit, including views of the override log