Transmittals
Formally issue project documents to an outside party, with a cover sheet and a per-recipient record of what happened to each copy
A transmittal is the formal act of issuing documents to somebody, and the record of having done it. It produces a cover sheet listing what went out, and a stored outcome for each recipient.
Transmittals are outbound only
There is no inbound lane, no reply capture, and no response tracking. Nothing on a transmittal transitions when somebody replies, because Struxen cannot observe that happening.
Two fields on the cover sheet look like tracking and are not: A response is requested and its due date are printed on the document and stored on the record. Nothing chases them, nothing goes overdue, and no surface will tell you a response arrived. The compose dialog says so where you enter the date. A due date the product could not observe being met is a due date it must not pretend to track.
Compose a transmittal
- Click Compose transmittal.
- Choose a purpose. Nine values: For review, For construction, For record, For approval, For information, For bid, For permit, Revised and resubmitted, As requested.
- Enter a subject and, optionally, a cover note. The note is the body of the cover sheet and prints verbatim.
- Add the items going out. Three kinds of line:
- a submittal on this project,
- a document on this project,
- a free-text line you type, which references nothing. Each line carries an optional description, a revision (free text, printed as you type it), and a physical copy count.
- Add recipients from the project directory.
- Click Compose.
Composing does not send anything. Every recipient starts at Not sent yet, and issuing the transmittal is a separate action with a higher permission requirement. That split is what lets you build a cover sheet, read it back, and only then put a document in an external party's inbox.
The number defaults to TX-014 style and can be overridden at composition.
Item labels are snapshots
The text on a line is captured when you compose and stored on the record. It is never re-resolved. A cover sheet that said "SUB-014 Structural Steel Shop Drawings" on the day it was issued keeps saying that after somebody renames the submittal. The underlying record is still linked, so the app can navigate to it; the snapshot is what the PDF prints.
Submittal and document lines are resolved against the live record on the server, and a record you cannot see is refused rather than silently dropped. Refusing is the honest answer: dropping it would issue a transmittal missing an item the sender believes they sent.
Recipients are directory contacts, never typed addresses
A recipient is a confirmed contact from the project directory, chosen by id. There is no field for an email address anywhere in this flow, on the screen or on the wire, so mailing an arbitrary inbox is not something the module can be asked to do.
Contacts that are only suggestions, for example an address a model read off a title block that no human has confirmed, are excluded from the picker. A machine guess can never become a send target.
If the party you need is not in the directory, add them there first.
Send it
Open the transmittal and use Send to N. Sending needs STANDARD access to the Documents tool, and the refusal names both the tool and the level, because "you do not have permission" is a dead end on the one action that mails an outside party.
The cover sheet is rendered before anybody is mailed. If the cover cannot be rendered, the whole send aborts and the message says explicitly that nobody was emailed.
What the record says afterwards
Each recipient gets its own stored outcome, never collapsed into a single success flag:
| Outcome | What it means |
|---|---|
| Not sent yet | Composed, no attempt made |
| Sent | The mail transport accepted it |
| Email is disabled in this environment | Nothing was sent, and nothing will be |
| Failed | The transport refused it |
| No email on file | That contact has no address in the directory |
Read the outcomes rather than assuming. The disabled outcome in particular is the honest default in any environment that has not explicitly turned mail on, and it is never rendered as success: putting "Transmitted" on a record when nobody was told anything would be a false statement on a legal artefact.
The audit trail records the same per-outcome counts, so "who mailed the architect what, and did it actually leave" has an answer.
Sent is final
Sent is terminal. A second press cannot re-attempt it, whatever mode you use. Re-mailing an architect a copy of a document they already have is the one failure this module can cause in somebody else's inbox, so a double click, a retried request, or a stale tab cannot produce it. A full send on a transmittal that has already reached everyone it can reach is refused as a conflict rather than quietly re-mailing the distribution.
No email on file is terminal for a different reason: there is no address on the record to try. Add one to the directory and compose a new transmittal.
Resend re-attempts only the recipients that can still change: not sent yet, disabled, and failed. The button says which recipients it will try.
The cover sheet
Cover sheet on the detail panel opens the transmittal as a PDF.
It is rendered on demand from the stored record and never stored as a file, which is what keeps a reprint from drifting from the record it represents. The date on the face is the issue date or, for an unsent transmittal, the composition date, never the moment you printed it.
Recipients print by name only. A cover sheet circulates: it goes into a package, gets scanned, gets forwarded. A printed list of email addresses serves nobody reading the document.
Downloading the cover needs only READ_ONLY on Documents, the same as viewing the record. Somebody allowed to read a transmittal is allowed to read the piece of paper that transmittal is.
There is no edit and no delete
A transmittal is a contemporaneous record of a formal issue. A register whose rows can be edited after the fact, or erased, is worth nothing to the people who read it in a dispute, and a cover sheet already mailed to an architect cannot be un-mailed by changing the row it came from.
A transmittal issued in error is superseded by issuing another one, which is what the paper process has always done.
The only write a transmittal accepts after composition is the send, and it only appends: the issue date is written once and a resend cannot move it.
Permissions
Transmittals are not a tool of their own. They are gated on Documents, because a transmittal is the act of issuing project documents and is held by the people who hold the documents.
| Action | Level |
|---|---|
| View the register, open a record, download a cover sheet | READ_ONLY on Documents |
| Compose | STANDARD on Documents |
| Send | STANDARD on Documents |
| Put a submittal line on a transmittal | Additionally READ_ONLY on Submittals |
The submittal check runs only when a submittal line is actually present. A transmittal of drawings and free-text lines asks nothing of the Submittals tool.
Limits
| Limit | Value |
|---|---|
| Recipients per transmittal | 25 |
| Items per transmittal | 200 |
| Transmittals read per project | 1,000 |
| Copies per line | 999 |
| Subject | 200 characters |
| Cover note | 5,000 characters |
| Item label | 300 characters |
| Item description | 500 characters |
| Item revision | 40 characters |
| Number label | 40 characters |
The recipient cap is a policy rather than a performance bound. A distribution larger than a project's actual party list is a mailing list, and this is not one.
Troubleshooting
Every recipient reads "Email is disabled in this environment." Outbound mail is off for this environment, so nothing was attempted and nothing will be. The transmittal itself is a valid record and the cover sheet is real; download it and send it through your own mail if the copy has to go out today. Raise the environment setting with your administrator.
A recipient reads "No email on file." That directory contact has no address. Add one to the project directory, then compose a new transmittal for that recipient. Pressing send again cannot fix it.
Send is refused as a conflict. Every recipient has already reached a terminal outcome, so there is nothing left to attempt. This is what stops a double click from mailing the distribution twice.
The send failed and said nobody was emailed. The cover sheet could not be rendered, and the cover is composed before anything is mailed. No inbox received anything. Retry; if it persists, check whether an item on the cover points at a record that has since become unreadable.
"Mail went out but the record could not be updated." Messages were sent and the outcomes were not recorded, so the recipient table is behind what actually happened. The response reports how many were attempted and how many are unrecorded. Reload the record before sending anything else, and do not resend: the recipients shown as unsent may already have their copy.
The register says it cannot be read. The storage behind the register did not answer. That is reported as an error rather than as an empty list, because "No transmittals" would be a claim that nothing was ever issued on this project.
You cannot add the architect as a recipient. Recipients come from the project directory's confirmed contacts. Unconfirmed suggestions are excluded. Confirm the contact in the directory first.
Composing is refused with a message about Submittals. One of your lines references a submittal, which needs READ_ONLY on the Submittals tool. Remove the submittal lines, or ask for Submittals access. The transmittal itself was never the problem.