Documents & drawings

The document and drawing register in IssuesId is built on three principles: immutable revisions, withdraw-not-delete, and pins survive uploads. Together they give you a record that holds up when someone asks "what was actually issued on the 14th?"

Immutable revisions

When you upload a new version of a document, the old version isn't replaced — it's archived as a prior revision. Every revision keeps:

→The original file, byte-for-byte.
→The uploader, timestamp, and any revision notes.
→The list of distributions that referenced it.
→The pins (for drawings) that were placed against that revision.

You can scroll back through a document's full history at any time. Nothing is ever overwritten.

Withdraw, don't delete

If a document is no longer current — superseded, cancelled, or issued in error — you withdraw it. Withdrawing:

→Marks the document inactive (it disappears from default registers and search).
→Preserves the file and its full history for audit.
→Leaves prior distributions intact so the proof-of-receipt trail isn't broken.

There is no "delete" for issued documents. This is intentional — if you could delete a document, the audit trail couldn't be trusted. The withdraw-not-delete model is what makes the register defensible.

Drawings and pins

Drawings are documents with one extra trick: you can drop pins (and free-form Fabric.js markup) on them to flag defects, locations, RFIs, or inspections.

Pins and markup are tied to a specific drawing revision. That has two practical consequences:

→Looking at rev B later, you see exactly what was pinned on rev B at the time — the markup is preserved with the file it was drawn on.
→Uploading a new revision starts a fresh markup canvas on that revision. Existing pins stay on the prior revision; they don't auto-migrate to the new geometry (which is usually what you want, because the layout has likely shifted).

The underlying defects, RFIs, and inspections the pins represent are independent of any single revision — they live in their own registers and survive new uploads. The pin is the visual marker; the defect or RFI is the record.

Finding a drawing

Drawings have their own index, separate from the document register, because you look for a drawing differently — visually, by where it is on the job, or by what changed recently.

→Thumbnails, so you recognise a plan without opening it. Switch to a list view when you'd rather scan names and codes.
→Search by name or drawing code.
→Filter by location, several at once — the levels or buildings you care about today.
→Filter by when it was last revised — the last 7, 30, or 90 days. This is the one that answers "what's changed since I was last on site?"

Open a drawing's revision history and you get the full timeline, a side-by-side compare between revisions, and an upload-new-revision action. If a revision was uploaded in error, setting an earlier one back as current is possible but permission-gated — it changes what the whole project sees as the working drawing.

On a phone, the markup tools collapse into a dock at the bottom of the screen, so pinning a defect on a plan is a one-thumb job rather than a pinch-and-hope.

The register

The register is the searchable, filterable list of every document and drawing on a project:

→Filter by status (current / withdrawn / superseded), type, revision, or discipline.
→Sort by upload date, name, or revision date.
→Bulk download a current revision set as a single zip.
→Export the register, as currently filtered, to CSV.
→Cross-tenant search is disabled by design — you only see documents from projects you're a member of.

Company documents

Policies, templates and standard forms that belong to the company rather than one job live in the Company documents register, opened from the dashboard. Company Admins and Managers add and revise them; Users can read them. Outside roles never see it.

Send to project(s) copies a company document into one or more project registers, with an optional note. The copy carries a Company badge, so the site team can tell a standard form from something drawn up for their job.

Who sees what

Being on a project doesn't mean seeing the whole register. Every document's audience is worked out in the same order, whoever is asking:

01Company Admins and Managers see everything. Nothing below narrows them.
02Confidential documents are for those two roles only. Everyone else is shut out, whatever else is set on the document.
03Restricted folders close everything beneath them to anyone the folder hasn't been granted to.
04The document's own grants, if it has any, decide who can read it.
05Otherwise, the grants on the nearest folder above it decide.
06Otherwise, the category decides.

The register's Visibility column shows the result for each document, and the Audiences view groups the register by who can read it. Client access appears there as Purchasers / Owners.

Per-document grants

Open a document's permissions to grant it to roles, named groups, or individual people, each at Can view or Can edit. Named groups are set up on the Document permissions page, so "the services consultants" is one pick instead of five.

A document's own grants replace the category rule for that document. They can open it to someone the category keeps out, or close it to someone the category lets in. Company Admins and Managers can change any document's grants; anyone with Can edit on a document can change that one.

Only Company Admins and Managers can mark a document Confidential. Clearing the flag brings back whatever grants it had before.

Folders

Company Admins build a folder tree for each project, and one for company documents, from Settings › Document folders, or from Manage folders and access in the register's Folders view. Grant a folder to roles, groups or people at Can view or Can edit, and everything filed under it follows those grants unless a document has its own.

Mark a folder Restricted and it narrows its whole subtree instead: nothing beneath it can be read by anyone the folder doesn't admit, whatever a subfolder or a single document says.

Filing a document can change who reads it, so moving documents into or out of a folder shows a before-and-after preview of each document's audience before anything moves.

Outside roles and the project

An outside role also has to be bound to the project before any of this applies: a trade through work assigned to their company, a tenant through their unit or project membership, a client or Building Manager by being set up on that project. A tenant or trade login can't reach a register on a project they've never been attached to.

All of these rules apply to search, exports and downloads too, not just the register listing. A document you can't see behaves as though it doesn't exist: it isn't findable by name, and its link returns a plain not-found rather than a message confirming the document is there.

Versioning by revision letter or number

Each revision has two fields: an ordinal (auto-incrementing integer used internally) and a label that's free text. The label is what users see and what appears in registers and distributions, so use whatever convention your organisation already follows:

→A, B, C… for design-style versioning.
→00, 01, 02… for engineering-style versioning.
→2025-04-12 for date-stamped revisions.

Pick one convention and stick with it across a project — mixing styles inside the same register gets confusing fast.

Upload, sign-off, distribute

The typical drawing flow:

01Upload a new revision with a short note ("Updated stair geometry per RFI 14").
02Mark superseded any prior revision the new one replaces.
03Distribute to the recipients who need to know (with acknowledgement required for contract documents).
04Track acknowledgements from the distributions panel, or from the document's Sent to panel, which lists every send with its revision, its recipients, and who has acknowledged.

The distribution carries the revision number forward, so even if you upload rev D tomorrow, the recipients of rev C have a record of what they actually got.