Transmittals & the exchange register

What a transmittal is

A transmittal is the formal, numbered way to issue documents: “under reference P0109-TX-0003, we transmit these five documents to these two organisations; please acknowledge.” Where a share is a convenience, a transmittal is a record — construction and engineering contracts usually require exactly this.

Each one carries:

• A reference issued automatically from the project’s sequence — <project token>-TX-0001, -TX-0002, …
• A subject and optional message.
• The documents, pinned at their current revision — what you transmitted stays what you transmitted, even after later uploads.
• The recipients — one or more of the project’s delivery partners.
• An optional acknowledgement due date.

Sending one

Open Transmittals in the sidebar’s Files group and press New transmittal — or press Transmit… on the file browser’s toolbar or in a document’s drawer (it arrives pre-ticked). The document picker lists everything transmittable grouped by folder, with a select-all per folder — tick a whole folder or individual documents. Then the recipients, subject, message, due date, send.

Rules the composer enforces:

• Only Shared, Published or issued documents can be transmitted — WIP and drafts refuse (issue them first).
• A document mid-upload can’t be transmitted.
• You can only transmit documents you can open yourself.
• Recipients must be delivery partners of this project.

Each recipient organisation gets an email and sees the transmittal in their portal’s Transmittals section, listing every document with a download link.

On your side, a transmittal lists every document it carried. If one of them is a document you can’t open — it was restricted after it went out, say — it shows as Restricted document, with no revision or suitability. It stays in the list so the transmittal still shows how many documents it carried.

Acknowledgements

The recipient presses Acknowledge receipt in their portal — once per organisation. The operator view shows each recipient’s state, and a transmittal past its due date with recipients still silent is flagged overdue. Acknowledgements also land on the exchange register, so the paper trail is complete without leaving the platform.

Transmittals from partners

Formal issue runs both ways. A delivery partner with the editor role can transmit its deliverables into your CDE — the ISO 19650 appointed-party hand-over — picking documents it has issued, giving a subject and an acknowledgement date, and issuing to the project team.

These arrive in the Inbox on your Transmittals page, badged awaiting receipt. Open one, check the documents, and press Acknowledge receipt; both sides of the exchange land on the register, so a partner can prove they issued and you can prove you received.

They take numbers from the same project sequence and follow the same rules as yours, including void. Two differences worth knowing:

• Nothing is granted to you. You could already see your partners’ issued documents — the transmittal is the formal record of the hand-over, not a new route to the files. (Another partner it is addressed to is granted the documents, as with a transmittal of yours.)
• Your team is emailed — the roles the project chose under Settings → Notifications — and the transmittal waits in the Inbox until someone acknowledges it.

A partner can only transmit documents it owns. Every transmittal it issues reaches the project team; it can address another delivery partner as well only where you have allowed it (May transmit to, under the partner’s access on the Partners page).

Voiding one issued in error

Sometimes the wrong file goes out, or the right file goes to the wrong party. Open the transmittal on the Transmittals page and press Void this transmittal…. You must give a reason, and it is shown to the recipients, so write it for them: “wrong revision attached — re-issue to follow”.

Voiding is deliberately narrow — it’s for correcting a mistake, not for tidying up. What happens:

• Access is withdrawn. The recipients’ access to those documents through this transmittal ends immediately, so the download links stop working.
• The recipients are told. Each gets an email — the issue was made in error, don’t use the documents, discard any copies, await a re-issue — and the transmittal shows a plain warning in their portal.
• The record survives. The transmittal stays on the register and in the recipient’s portal, marked void with your reason. It is never deleted and its number is never reused: someone who already downloaded the file has to be able to find out it’s dead.
• Nothing else is touched. If a recipient can also reach a document through a shared folder, or through a later transmittal, that access is unaffected — voiding withdraws this issue, not every route to the document.
• The void is audited, with who did it, when, and the reason.

A voided transmittal can’t be acknowledged and never counts as overdue. To put the correct documents out, issue a new transmittal — it takes the next number, which is exactly what the audit trail should show.

The exchange register

The Exchange register (in the sidebar’s Files group) is the single chronological record of everything exchanged with outside parties, across every mechanism:

Row kind	Meaning
received	A partner or bidder sent you a file.
distributed	You issued/shared/published a document to a party — including outside share links (named or anyone with the link).
transmitted	A document went out under a transmittal reference. A voided issue stays on this row, marked VOIDED with its reason.
acknowledged	A recipient confirmed receipt of a transmittal.

Every row shows the counterparty, the document, the direction and the timestamp. Export CSV gives you the whole register for contract records or an audit — it’s the file you hand over when someone asks “prove what was issued to whom”.

You see the register as far as you can see the documents in it:

• A row about a document you can’t open — one in a restricted folder, or one restricted since — is left out.
• A row about a document that was legally erased stays, named only Document, if you could open it before it was erased.
• A bid file you can’t see is listed under the name of the requirement it answers, not its file name. When it arrived still shows.
• Transmitted and acknowledged rows always show, with their document count.

Unless you’re a workspace admin, the register page says so: Shows the documents you can open. The line is there whenever your view could be cut, whether or not anything is actually left out. So it tells you nothing about what exists.

The CSV export follows the same rule, and says so in its name: your export downloads as exchange-register-your-view.csv. A workspace admin’s complete register downloads as exchange-register.csv. If you need the complete record for a contract or an audit, ask a workspace admin for it.

Partners see their own transmittals in their portal exactly as they were issued, including a document restricted after it went out: it is the record of what was put in their hands.