Whole project — everything, folder structure preserved.
Updated files only — the same tree with the empty placeholder folders left out.
A single folder — started from the folder itself in Files & Evidence.
All three are prepared in the background. Close the tab if you like; the package will be waiting on the Downloads page.
Choosing between them
| Whole project | Updated files only | Single folder | |
|---|---|---|---|
| What's in it | Every folder and every document. | Only folders that actually contain documents. | One folder and everything beneath it. |
| Empty folders | Kept — the structure is the point. | Left out. | Kept within the folder. |
| Where you start it | The project's Downloads page. | The folder's menu in Files & Evidence. | |
| Good for | Handover. The full record, in the agreed shape. | Sending someone what exists, without a skeleton of empty folders. | One discipline, one trade, one stage. |
| Speed | Slowest | Faster | Fastest |
Excluding rejected documents
The Whole project option has a tickbox for leaving out documents that were rejected in review. The folder structure is identical either way — only the rejected files are dropped — so a handover package keeps the shape everyone agreed on.
If you tick it and see “Every file in scope was left out by the rejected-documents filter”, then every document in the project is currently rejected. Untick the box, or fix the rejections first.
Why a big export takes a while
Preparing a package means fetching every document from storage one at a time, rebuilding the folder tree, compressing it, and uploading the result. The fetching is the slow part, and it scales with how many documents there are — not with how big the ZIP ends up.
A small project is ready in well under a minute. A large one with thousands of documents can take several minutes, and a very large one can run long enough to fail. If that happens:
On a project with a large checklist, most folders are placeholders waiting for documents. Dropping them can cut the work dramatically while leaving every actual file in place.
Take one stage or discipline at a time from Files & Evidence. More steps, but each one is small and finishes quickly — and you can run them while other work continues.
If you need the export organised differently — by stage, by discipline, or to a client's own layout — the Downloads dialog has a Custom Folder Structure option that emails us. We prepare it for you. This is also the right route for a package that keeps timing out.
Reading the Downloads page
Each request appears as a row with a live percentage while it builds. When it's ready you get a Download button, and the package stays available so you can come back to it.
Mark as failed appears on a row that is still building. Use it when a request has clearly stalled — it clears the row so you can start a fresh one, and it does not interrupt any other download.
“Copy link” shares the package with anyone who has the link. It copies a public address for the ZIP — no DocuBuild account, no project membership and no sign-in is needed to open it. That is exactly what makes it useful for sending a package to a certifier or a client who isn't on the project, and exactly why it should never go into a public channel, a shared inbox, or anywhere it might be forwarded on. The link keeps working after the download row is deleted.
What a downloaded package contains
- The latest version of each document. Superseded versions stay in DocuBuild, where their history is visible; they aren't included in the ZIP.
- The project's folder structure, as it appears in Files & Evidence.
- Documents only. Comments, decisions, approval history and the activity trail live in DocuBuild — for those, use the checklist export instead, which produces a spreadsheet rather than a ZIP.