File Folders: File Transfer & Deliverables

A shared location for reports, models, reference material, and other project files — with internal and external sharing.

Overview

File Folders is the shared home for project files that are not managed as structured records — reports, models, reference material, photo sets. In the project nav it is three destinations: two sibling folder trees, Deliverables and File Transfer, plus a Settings view for managing shares.

Just as important is what does not belong here: a sheet belongs in Drawings, a specification section in Specifications, a formal supplemental issuance in ASIs, and a formal question or review package in RFIs or Submittals. A file dropped in a folder carries no review history, no ball-in-court, and no notifications.

Warning

Never use a file share as a substitute for a formal RFI, Submittal, ASI, or contractual notice — and don't duplicate structured records into File Folders unless the project's documented process requires a packaged copy.

Watch first

Video: Navigate, upload, and share (~30 sec)

Move through the folder tree, upload a file, and send it as both an internal and an external share.

Deliverables or File Transfer?

Deliverables and File Transfer share the same mechanics — both hold folders, both accept uploads, both can be shared — but they are not organized the same way, because they do different jobs. One convention applies everywhere: put the date first, in YYYY-MM-DD form, in any folder or file name that needs one — and follow it with what the thing is. A date alone is not a name.

A comparison chart of the two areas. Both offer folders, uploads, and shares, everyone can view and download, and the design team can upload to both. The one difference shown: uploads from the CM and consultants are File Transfer only. A footer notes that neither area replaces a structured record — a sheet, specification section, ASI, RFI, or Submittal always belongs in its own module. — Same mechanics, different jobs. The permissions each area grants by default are what make the distinction real rather than a matter of habit.

Deliverables is outbound. It holds what the design team issues to the project, and on a typical project most companies get view and download rights there but cannot upload — treat what you find in Deliverables as the issued copy. On a small or simple project it is organized as folders by date; a larger project adds a top-level folder per deliverable type, with date-organized folders inside.

File Transfer is the shared working area — markups going back and forth, a model someone needs to look at, a photo set from a site walk. The CM and consultants can normally upload here as well as read. It is organized by company: each company gets one top-level folder and organizes its own content within it.

Two folder trees side by side. Deliverables is organized by what and when: on a small project, date-first folders such as 2026-05-12 — Issued Set; a larger project adds a top-level folder per deliverable type, such as Drawing Issuances or Reports & Studies, each holding date-first folders inside like 2026-06-15 — Envelope Study. File Transfer is organized by company: one top-level folder each for the architect, the CM/GC, and each consultant, with each company organizing the contents of its own folder. — File Transfer is organized by who; Deliverables by what and when. Date-first names keep both sorting chronologically.

Exact rights differ by project — your company's access is set per project in Settings. If you can see one area and not the other, that is configuration, not a fault.

Internal or external share?

The choice is decided by the recipient, not by the files. The question to ask is whether the person receiving this is already a member of the LiveArch project.

The files can be identical either way. What changes is how the recipient gets in, and for how long.

An internal share is a pointer. The recipient signs in as themselves and sees the files in place, governed by the permissions they already have. Nothing leaves the project, and there is no link to expire.

An external share creates a way in for someone with no account. The recipient proves they control the mailbox the share was sent to by entering a one-time PIN — so the credential is their inbox — and then reaches only the files you selected, for only as long as the share is live.

Send an external share when the recipient should see one package and nothing else: a vendor pricing a scope, a fabricator who needs three sheets, an authority reviewing one submission.
If the same person keeps needing external shares, they probably should be a project member instead — ask the project team about adding them.

The Settings view under File Folders lists every active share — its recipients, contents, and remaining availability. Revoke or replace a share that went to the wrong recipient or carried the wrong files.

Support

Questions or issues? We're happy to help — , or use the contact form if you're signed out.