Document Control User Guide
Getting the right approved document in front of the right operator, and proving they read it
Getting the right approved document in front of the right operator, and proving they read it
A document does not reach an operator because it exists in ProAlert. It reaches them because somebody linked it to the thing it governs, and because it is approved. That linking is the setup work, and it is exactly what makes the panel trustworthy: what an operator sees is there on purpose.
ProAlert does not keep a list of "documents for machine 14". It works the question out each time, from what the machine is actually running.
Drafts and obsolete revisions are never visible to an operator. Not hidden behind a filter they could clear, not greyed out: excluded. Every document picker in the system is approved-only as well, and the server checks again when the bytes are requested, so a draft cannot reach the floor through a stale link or a copied URL.
The result is recalculated whenever the context changes, which in practice means at changeover. Start a different product on the same machine and the document list changes with it.
Two places, depending on what is in front of them.
| Where | What it shows |
|---|---|
| Schedule HUD documents panel at the work centre |
Everything relevant to the product currently running on that asset, grouped by type, with organisation-wide documents in their own section. |
| Docs tab ProAlert mobile app |
The same resolved list on a phone or tablet, for people who are not standing at a station. |
ProAlert does not change how you author documents. Word, Excel, PDF and CAD stay where they are. ProAlert provides the controlled storage, the lifecycle, the linking and the point-of-use access around them. Existing documentation can typically be imported without re-authoring, though revision metadata, an approval baseline and the links that decide where it appears still have to be set as part of bringing it under control.
| Link to | Use it for |
|---|---|
| Product | Control Plans, work instructions, inspection criteria. This is the link the start gate checks. |
| Asset | Machine setup sheets, lockout procedures, anything tied to the equipment rather than the part. |
| CMMS asset | Maintenance manuals, service bulletins, calibration records. |
| Work order | Documents relevant to one job rather than to the equipment permanently. |
| Business resource | Company and plant-wide policies. See Organisation-Wide Documents. |
Every upload gets a version and a revision, defaulting to 1 and A. Do not leave these blank thinking they are optional. Acknowledgement is recorded against the exact version and revision a person read, so a document with no revision can never re-prompt anyone when it changes.
Only one approved document of a given type can apply to a given context. One Control Plan for a product, not three. The database enforces this rather than trusting the screen, so an attempt to approve a second one is refused rather than quietly accepted. That constraint is the whole reason an operator never has to choose between two documents.
Whether an upload lands as a draft or goes live immediately is set per document type. Types marked as requiring approval land in DRAFT and wait. Approvals are worked from Quality → Document Approvals.
By default the person who uploaded a document cannot be the person who approves it. This is deliberate: an approval chain one person can walk end to end is not a control. It can be turned off for a plant that genuinely needs it, on the Document Control Settings screen, and doing so is a decision worth recording. A document with no recorded uploader is exempt, because there is nobody to separate from.
Approving requires a signed-in user with a real identity on file. An approval that cannot be attributed to a person is refused outright rather than recorded against a system account.
Only an approved document can be revised. Start a revision and you get a new document that records what it supersedes, so the chain back through every earlier revision stays intact.
The ordering in step one is not cosmetic. Two approved documents of the same type cannot share a context, so the predecessor has to step down before the successor can step up.
A document can be marked as one that must be read. That flag is set per document, not per document type, so a single critical work instruction can require acknowledgement without every work instruction in the plant doing so.
An acknowledgement records one person, one document, one version and one revision. Nobody acknowledges on anybody else's behalf, and a supervisor cannot acknowledge for a team. What a supervisor gets is visibility: who has acknowledged the current revision and who has not, which is what compliance follow-up actually needs.
Because the record is pinned to a version and revision, a revision bump makes every earlier acknowledgement stale by definition and re-prompts everyone. If someone tries to acknowledge against a revision that is no longer current, they are told what the current one is rather than having a misleading record written.
Some documents belong to the company or the plant rather than to a part: a safety policy, a quality manual, a code of conduct. Link these to a business resource node and they reach everything beneath it.
They appear in their own section on the operator's panel, labelled with the part of the organisation they came from, so a corporate policy is distinguishable from a plant one at a glance. A policy that asks to be acknowledged is prompted for like any other document.
A missing corporate policy will not stop production. The start gate asks whether the part has what it needs to be made, which is a different question from whether the company's paperwork is complete.
ProAlert can check, at the moment a run is started, that the governing documents are in place. This is configurable, and it can be advisory or blocking according to your policy. Nothing locks down a line unless you configure it to.
| Check | When it applies |
|---|---|
| A required document is missing | Always. If the product has no approved Control Plan, that is a gap in control, not a preference. |
| A required document is unread | Only on assets configured to require document review before start. Turn it on where it matters and leave it off elsewhere. |
The operator's screen checks first and shows what is outstanding, so the person is told what is missing rather than simply refused. The server decides. A client that is out of date or has been tampered with cannot talk its way past the gate.
| Role | Document access |
|---|---|
| Operator | View current, approved documentation for the work in progress, and acknowledge the revisions they are required to read. |
| Supervisor | Operator capabilities, plus visibility of who has acknowledged the current revision and who has not, for compliance follow-up. |
| Engineer | Upload, link, revise, and submit documents for approval. |
| Quality / Admin | Approve, publish, obsolete, and audit. Separation of duties applies: no approving your own upload. |
When the same product runs on different equipment, machine quirks, tooling notes and setup differences are captured inside the controlled document itself. ProAlert does not support appendix-style amendments or asset-specific overrides held as separate metadata.
This is a deliberate design decision rather than a limitation. Appendix-style addenda introduce drift, and they create real ambiguity at audit about which combination of documents was in effect at a given moment. One controlled document per process variant, approved as a unit, is the conservative choice.
If your plant currently manages variation with addenda, validate the one-document-per-variant approach with your registrar and your customers before migrating. It is the more defensible structure, but it changes how your document set is organised, and that is a conversation to have early rather than during a surveillance audit.
ProAlert supports the ISO 9001 clause 7.5 documented-information controls through identification, revision control, approval status, effective-date management and point-of-use availability, and is designed to support IATF 16949 document and engineering-change control requirements. Whether a given plant satisfies a clause still depends on its configuration and its working practice. Document control supports compliance; it does not replace the discipline behind it.