Working with files

Everything on this page happens under the project’s Files group in the sidebar — the group lists All files plus the top-level standard folders you can access (each a one-click shortcut into that section). All files is the browser: folder tree on the left (carets collapse and expand branches), the current folder’s contents on the right — subfolders appear as rows you click into, Drive-style, with breadcrumbs to climb back — and a details drawer when you click a document. The tree remembers which branches you left open and the folder you were in, per project, so a refresh drops you back where you were. The layout is yours to adjust too: drag the divider to resize the tree panel, and drag a column edge to resize the table’s metadata columns (the Name column takes up whatever’s left) — both stick per project.

The toolbar’s Search all folders… box searches the whole project tree by document title (two characters or more) — a result row shows where the document lives; clicking it opens that folder.

The address bar follows you into folders. Clicking into a folder updates the URL, so the browser’s Back and Forward buttons walk back through the folders you visited, and you can copy the link and send it to a colleague — they land in the same folder, provided they’re allowed to see it. (A link to a folder someone isn’t cleared for simply doesn’t open it; it is not a way around access.)

Two shortcuts worth knowing:

• Right-click any row (or click its ⋮ button). A document offers Details / Preview / Download / Rename / Move / Share with partners / Transmit / Delete… (last, in red — see Retention & erasure); a subfolder offers Open / Share / Add subfolder / Rename / Move / Retire — the same actions as the tree’s ⋯ menu.
• Tick the checkboxes to act on several documents at once: Share with partners, Transmit, Download (zip) — one ZIP of everything ticked, each download recorded as usual — or Mark issued, which takes one suitability for all the ticked WIP deliverables, marks ticked drafts issued, and skips anything already live.

Uploading

Three ways in — they all end the same:

• Drop files anywhere on the page — a “Drop to upload to «folder»” overlay confirms where they’ll land (the folder you’re viewing). Several at once is fine, and whole folders too: the directory structure is recreated under the folder you’re viewing (where the template’s folder-changes setting allows — a refused subfolder fails its own files with the reason, never the rest of the batch).
• Upload files / Upload folder… buttons in the toolbar.
• Register a document for a controlled document with a generated name (below).

Uploads queue in a tray at the bottom-right corner, each file with its own progress and outcome — one bad file never stops the rest, and you can keep browsing while they run.

You’re always told when an upload worked. A confirmation appears naming what happened — “New version P03 of «STR-MUR-SD Package» uploaded”, or “5 files uploaded” for a batch — and a file that failed says so rather than disappearing quietly. The same confirmations appear in the partner portal.

You can only file into a folder whose documents you could open. A new document takes its folder’s clearance — an [admin-only] or [internal] badge on the folder says it’s narrower than usual — so filing into a folder classed above your own clearance would make a document you could no longer see. Such an upload (small or large) or registration is refused before anything is stored, with a message saying why: choose another folder, or ask an organisation admin to file it.

If a file you drop has the same name as a document already in the folder, a prompt asks what you meant: Upload as new version (the bytes become the next revision of the existing document), Keep both (a separate document), or Cancel. Other files in the same drop upload as usual while you decide.

Issue on upload

When the destination is a CDE folder or a [workflow] folder, the upload panel offers Issue on upload (with an S1–S4 picker for CDE deliverables). Each file is issued as its bytes land — controlled documents go WIP → Shared, descriptive files draft → issued; anything already live is skipped, and a file whose issue fails simply waits as a draft (the upload itself never fails).

The filename decides what the file becomes (see Files overview): a name matching the project convention registers as a controlled document; anything else becomes a descriptive document titled with its filename.

Big files

Files over 150 MB upload straight from your browser to storage in parallel chunks, with a progress bar — multi-gigabyte files are fine. In a multi-file batch, big files take their turn one at a time (the rest queue behind). Keep the tab open until the bars complete; a version stuck mid-upload shows an uploading chip and is swept away automatically if abandoned.

Registering a controlled document

Click Register a document and fill in the dropdowns:

Field	Meaning
Originator	Which organisation authored the file (each participant has a short code, e.g. ABF — set under Clients & vendors → the organisation → Participant code).
Volume	Which part of the works it belongs to, plus an optional room-type suffix.
Level / floor	Where it applies (01, B1, XX for “not level-specific”).
Type	What kind of container it is — drawing, model, schedule… (codes from the workspace naming register).
Discipline	Whose discipline — architecture, structure, MEP…

The form shows the generated container name live, for example P0109-ABF-XX-01-DR-A-0001-S0-P01 — the sequence number is issued automatically, S0 means “work in progress”, P01 is the first preliminary revision. Pick the file, press Register, and the document exists in the current folder at state WIP.

Tick Issue on upload and choose a suitability (S1–S4) to register and issue in a single step — the deliverable lands Shared rather than WIP. Issuing is still its own audited transition: if it fails, the WIP document is safe and you can issue it later from its drawer.

Versions and revisions

Documents are never overwritten:

• New version (drawer toolbar) files a new revision — P01 → P02 while preliminary; published documents continue on the contractual C01, C02… series. The previous version stays on the record, marked superseded.
• Restore (next to any old version) copies that version’s bytes forward as a new revision — history is never rewritten to “go back”.
• Download always tells you exactly which revision you’re getting, and every download is recorded.

Spotting a versioned file at a glance

Once a document has more than one version its row shows a “3 versions” chip. Click the chip to open the drawer straight at the version list.

Dated file names. Many teams end every filename with the date it was produced — STR-MUR-SD Package-2026-05-28. That’s a fact about the version, not about the document, so once a second version exists the displayed name drops the trailing date and reads STR-MUR-SD Package. Each revision still carries its own dated filename, and the stored name is untouched — it’s what search matches on. Single-version documents show their name exactly as uploaded.

This also means dropping …-2026-06-14.pdf into a folder that already holds …-2026-05-28.pdf offers Upload as new version, instead of quietly creating a second document that looks like a duplicate.

Choosing which revision to open

The drawer’s Versions list opens, downloads or restores any revision, and Preview carries a version switcher — flip between revisions in place, which is what you want when comparing one issue against the last.

Pinning a task on a drawing

A PDF’s preview renders page by page, so a task can be raised at a spot on the drawing: Drop a pin in the viewer’s toolbar, click the page, and the task dialog opens with the drawing, revision and page filled in. Pins are numbered per document, drawn on the page, and belong to the revision they were made on — a pin on an older revision reads on superseded revision. Clicking a marker and then Open task opens the task beside the drawing, so you never lose the spot; Open in Tasks goes to the list. The full story is on Tasks.

If the page view cannot load (it fetches the file directly from storage, so the documents bucket must allow the app’s origin to read it), the preview falls back to the browser’s own PDF viewer and says so; pins need the page view.

Putting revisions back in the right order

Loading a project’s history by hand, it’s easy to upload P03 before P02. Drag the rows in the Versions list to correct it: the revision labels stay put (P01, P02, P03) and the files move between them, so the newest revision label always holds the file you meant.

Reordering is offered only while the trail is still private to the project — two or more versions, no upload in flight, and the document has never been shared with a partner or pinned to a transmittal, and is still WIP (or, for an ordinary file, not yet a formal record). Once something has gone out, its revision history is part of the record and stops being editable. If you need to correct a document past that point, file a new version instead.

The details drawer

Click any row and the drawer opens on the right. You only ever see, and act on, documents you can open: one classed above your clearance never appears in your Files, and anything aimed at it — a link someone sent you, say — answers as if it did not exist.

• Header — title, container name, state badge, and a from partner chip when a delivery partner uploaded it.
• Vitals — revision, size, modified date, file type (a Drive-style icon plus the extension — PDF, DWG, XLSX), and the folder it lives in. The folder is a link: click it to jump to that folder (the tree opens to it) and the drawer closes.
• Clearance — the document’s level, and its pocket if it has one. With filing:admin you can change it with Change…, but only to a level you can see yourself: the list leaves out the levels above your clearance, because a document classed there would vanish from your Files. To class a document above your clearance, or into a pocket you’re not in, ask an organisation admin.
• Tasks on this drawing — every task pinned on the document (for a PDF or image with a revision): open ones first, then closed, each with its number, title, status, owning company, due date, the revision and page the pin sits on, a link to the task and Open at pin, which opens the preview at that spot. A pin left on a superseded revision says so. Tasks you may not see are not listed — a pin number can be missing for that reason.
• Toolbar — Preview (PDFs open in a page viewer with page navigation, zoom and the task pins; images render as they are, with the pins over them; any other type — a CAD drawing, a Word doc — shows a Download to open card, never a broken image), Download, New version, Rename…, Move….
• Lifecycle — the one action that currently applies (Issue / Publish / Archive / Mark issued). See Lifecycle & sharing.
• Sharing — which partners can see it, plus outside share links.
• Versions — the full revision history, with per-version open, download, restore and (while the document is still private to the project) drag to reorder. See Versions and revisions.
• Activity — everything that happened to this document, newest first.
• Delete — at the bottom, and on the row’s right-click menu; see Retention & erasure.

Rename and move — “within rules”

Rename is on the row’s right-click menu and in the details drawer. Type the new name; the extension looks after itself.

The new name is the file’s real name. Download it and it saves under the name you gave it; in a bulk ZIP it appears under that name; and a partner who downloads it — from their portal or from a transmittal — gets that name too. You don’t need to delete and re-upload a file to fix its name.

Two things deliberately don’t change: the file type (renaming a .dwg doesn’t make it something else — the extension follows the bytes, not the typing), and each version’s record of the name it arrived under, which stays in the document’s history as evidence of what was uploaded.

Who can rename what

Renaming depends on who you are as well as what the file is.

• Project managers and co-managers can rename any file on the project, at any point in its life — including a published or archived controlled document, and a record issued in a [workflow] folder. A wrong name on a record is a project-lead call to fix; the rename is recorded in the file’s history like any other, showing the old name and the new one.

  Renaming a record renames it for everyone

  A rename is not cosmetic — it changes the name the file downloads as, for everybody. On a published controlled document that replaces the ISO container name in the downloaded filename, and a partner who re-downloads something already transmitted to them will get the new name. The register row still shows the generated container name underneath, and each version keeps the name it arrived under in the history, so nothing is lost — but if a name has already gone out on a formal issue, consider whether a new revision is the honest correction rather than a rename.

• Everyone else on your team can rename anything that is not yet a formal record. A published or archived controlled document refuses rename — its filed name must keep resolving — and so does an ordinary document once it’s a record: issued in a [workflow] folder, or handed over by a partner. A live file in any other folder renames freely, including the everyday case of a file dropped straight into a normal folder, which goes live the moment it lands. To correct a record’s name, issue a new revision — or ask a project manager.

• Partners, in their own portal, can rename a file they uploaded, and only while it is still a draft — a controlled document still WIP, or an ordinary file they haven’t handed over yet. Once they issue or share it, the name has gone out into the project and is no longer theirs to change; if it is wrong from then on, the project team fixes it. Partners never rename anyone else’s files.

• The client lead is treated as everyone else here, not as a project manager: it’s a delivery-leadership decision, not a client-side one.

Where rename is refused, the menu simply doesn’t offer it — the app asks the server what you personally may do with each file rather than guessing, so what you’re shown and what’s allowed can’t disagree.

Moving is unchanged and unaffected by the above: it keeps a controlled document inside the controlled part of the tree, and the underlying stored file and its confidentiality never change.

Changing the folder structure

Right-click a folder in the tree — or hover it for the ⋯ menu — to reach the structural changes: Add subfolder, Rename, Move and Retire. How much you can change is the template’s “Folder changes on projects” setting:

• Add only (the usual setting): add your own folders where the template marks space for them, and rename/move/retire the folders your project added. The standard folders that came with the template are fixed — they change through the template itself (below), so every project on the standard stays identical.
• Locked: no project-level changes at all.
• Full: standard folders may also be renamed, moved or retired per project; every divergence is recorded and shows on the admin Drift tab.

The rules that keep changes safe:

• Nothing is ever deleted. Retiring hides a folder from filing; the record and its history stay. Retiring a folder that still holds live documents makes you choose first: move the contents to another folder, or keep them in place as a read-only record. Files already pending deletion don’t count — they stay with the retired record and remain on the Retention queue. Retire is also how you remove a subfolder you added by mistake — and it isn’t one-way: Add subfolder with the same name in the same place restores the retired folder, history intact.
• A move that changes who can see things stops and asks. Delivery partners’ folder access follows the tree — if moving a folder would put it inside (or take it out of) a partner’s granted area, the change pauses and tells you how many partners would gain or lose sight before you confirm.
• Files never move in storage. Renames and moves are recorded against the folder — documents and their history are untouched.

When the template itself changes

When a workspace admin activates a new template version, every project on that template reconciles rather than being rebuilt: additions and renames flow through safely; anything that removes folders or changes who can see what waits for a human on Admin → Filing → Reviews. Your own added folders ride along untouched — unless the template retires the folder they live in, which is flagged for you to re-home them first.

Switching a project to a different template

A project that hasn’t filed anything yet can swap templates outright: Project settings → Filing → Filing template shows where the tree came from and a picker over the active templates. The switch replaces the empty tree and refuses the moment any document exists (even one pending deletion) — a tree holding documents only changes through reconciliation. Any partner folder access on the old tree is revoked by the swap; re-grant it on the Partners page. The usual case: an older project was backfilled with its methodology’s default and you want a different standard.

The rest of the Files group

The sidebar’s Files group carries the record-keeping pages alongside the browser:

• Transmittals — issue and track formal transmittals; see Transmittals. (The Transmit… button on the browser toolbar and in a document’s drawer starts one too.)
• Partners — see Delivery partners.
• Exchange register — the record of everything exchanged; see the exchange register.
• Activity — a project-wide feed of filing events (uploads, issues, downloads, shares, transmittals), with who did what and when. It only shows events for documents you can open: a document you can’t open, or one restricted since, leaves no trace in your feed. A document that was legally erased still shows its events, as Removed document, to anyone who could open it before it was erased.
• Retention — pending deletions and the erasure ledger; see Retention & erasure.