Running a quality-system document set

Set up documents that carry codes and versions and cannot be published without a review.

What an auditor looks for is this: every document has a unique code and a version, someone read and dispositioned it before publication (and that step cannot be skipped), who said what is on record, and none of it can be rewritten afterwards. This scenario sets that up.

Steps

  1. 1Create a board of type Docs. It stands apart from task boards; its tabs and permission matrix follow page work.
  2. 2Under Space Settings > Document Codes define the code series: prefix, separator and number of digits (MAN.4-TL with two digits, for example).
  3. 3Create a page template and bind it to the series. Every document created from it takes the next code automatically; the code shows in the tree, in search, in the header and in PDF/Word exports.
  4. 4Set up the roles. In a docs space the built-in roles appear as Editor, Commenter and Viewer. If you want the "can write but cannot publish" split, define a custom role: "Edit documents" on, "Publish documents" off. Turn on "Comment on documents" as well if they should comment; edit rights alone do not allow commenting.
  5. 5Give whoever manages templates, series and page permissions the "Document settings (templates, code series, page permissions)" permission. It is separate from member management: a quality manager should not need member rights just to define a template.
  6. 6For a narrow page (a compensation study, say) grant per-page access to a person, role or group. A restricted page is not even listed, or found in search, for someone without access; the restriction does not pass to subpages, so restrict those separately. Opening a new page (blank, from a template or from a Word or Markdown file) requires the "Edit documents" permission; adding a page under another page or duplicating one requires edit rights on that page. A page you cannot edit opens read-only.
  7. 7Choose the pre-publication process and set its rule: under Space Settings > General > Publishing rule a completed review is required by default, and you can require a granted approval too; with both ticked, every publication needs both, and the "Order" option sets their sequence: "Parallel" (the default, the two run independently), "Review first, then approval" or "Approval first, then review". The order is enforced: a step whose turn has not come cannot be started. Use an approval chain when one signature is enough, or start a formal review when comments have to be collected and dispositioned. The rule keeps these processes from being skipped: a review or an approval backs a single publication, and every new publication needs its own.
  8. 8While a review is open or an approval is pending the page cannot be published, and during a review the content freezes too. When it completes, "Publish" opens and the published version is stamped onto the review. Adding an attachment to a published document opens a new draft version (e.g. 1.0 → 1.1) and needs republishing. Once an approval or a review completes, the document cannot be edited until it is published (content, title, attachments, version restore); an approval request approved by mistake can be withdrawn with "Withdraw approval". The exception: with the order set to "Approval first, then review", the document can be edited during the revision round of the review started after approval, since the findings have to be worked in.
  9. 9When an auditor asks for an earlier version, open that publication from the document’s "Published versions" list: content and attachments appear as they were at publication, and it downloads as PDF or Word. The "Review" or "Approval" badge on the entry shows which process the publication went through; the file opens even if the attachment was deleted afterwards.

Numbers are never reused: a deleted document’s code is not issued again, so no two documents can share a code in an audit. Gaps in the series are normal and not a fault.

Related pages: Docs space, Formal review, Quality standards, Roles & permissions.