Submittals
Route shop drawings and product data through a multi-step review to a stamped disposition, with per-company status names and a ball-in-court clock that cannot be rewritten
The submittal register is the log of what has been submitted for review, who is holding it, and what was stamped on it. Each row carries a CSI spec section, a number, a review workflow, and a disposition.
The register has two views, selected by the tabs above the table: Log, the flat register, and Packages, the same rows grouped by package.
Create a submittal
- Click New submittal.
- Enter the Spec section and a Description. Both are required.
- Fill in whatever else the record needs: title, type, responsible contractor, received from, package, cost code, the date block (submit by, received, final due, required on site, lead time), location, and distribution.
- Optionally turn on AI pre-review, which adds the AI review as the first step of the workflow.
- Click Create submittal.
The number is not editable in the dialog. It is allocated on the server from the project's sequence, in one of two modes:
- Spec section (the default). The sequence restarts per CSI section, so
23 05 00-1.0and26 05 00-1.0coexist. This is what a spec-driven submittal log looks like on paper. - Project. One sequence across the whole job.
A new submittal lands in Submitted. It has not gone out to anyone yet. Sending it for review is a separate action, Send for review, which opens the first step of the review workflow.
The eight statuses
| Status | Renameable | Meaning |
|---|---|---|
| Submitted | No | Received, not yet sent for review |
| Pending | No | Out for review |
| Approved | Yes | |
| Approved as Noted | Yes | |
| For Record Only | Yes | |
| Revise and Resubmit | Yes | Returned; the manager decides what happens next |
| Rejected | Yes | Returned; the manager decides what happens next |
| Void | Yes |
The two lifecycle statuses are locked, and they are locked for a reason: every "what is outstanding" query and every cross-project roll-up keys off whether a submittal is still open. A company that renamed Pending to "With Architect" on one job and "In Review" on another would make that roll-up meaningless.
The six disposition statuses are the words that appear on a stamp, and stamps genuinely differ by firm, so each one accepts up to 12 company aliases. The first alias is the display label; the rest are accepted synonyms, so a search or an import for "No Exceptions Taken" resolves to Approved. An alias may not be blank, may not be claimed by two statuses, and may not collide with a built-in status code.
Approved, Approved as Noted, For Record Only, and Void are final. Revise and Resubmit and Rejected are closed to reviewers but still actionable by the submittal manager, who can resume the review or spin a revision. That is deliberate: making them final would also make a rejected submittal impossible to void.
The review workflow
Steps run entirely inside Pending. Each step is a position in an ordered chain with one or more assignees, and the step that is open holds the ball.
The workflow's rolled-up outcome is what moves the record out of Pending:
- Every step approved: the record lands on the most restrictive approval recorded across the chain.
- Any reject-class response: the record lands on Revise and Resubmit or Rejected, and the ball returns to the submittal manager.
Nothing rewrites, reopens, or reorders a step that has already closed. Resuming a returned submittal appends a fresh attempt; revising creates a new record. An in-place rollback would overwrite the step it rolled back to and silently corrupt every ball-in-court duration drawn from that record, which is the defect this design exists to avoid.
Who can do what
| Action | Who |
|---|---|
| Send for review, resume, void, supersede | The submittal manager (submittal.manage) |
| Record a disposition (approve, approve as noted, file for record, revise and resubmit, reject) | An assignee on the open step, or the manager |
| Comment | Anyone with STANDARD on Submittals |
The manager can dispose of a record directly, which is what "the manager closed it out" means on a job where the architect responds by email.
Buttons are driven by the machine, not by the UI. An action you cannot legally take right now does not appear, rather than appearing and failing on click.
Ball-in-court and the clock
Ball-in-court is derived, and every interval it passes through is appended to the record as a closed segment. Segments are never deleted and never reopened, so the register can report how long each party held a submittal and a report drawn from it cannot be invalidated by a later action.
The register shows the current holder and how long they have held it. The CSV export carries both the current hold and the total days in court.
AI pre-review
The AI pre-review is modelled as an ordinary workflow step rather than a button on the side: it has a position, an assignee, a ball-in-court, and a response recorded immutably in step history. Its verdict closes the step and advances the workflow to the first human approver exactly as a human response would.
It is the one paid action in this module, metered against the project's credits. The AI has no "for record only" verdict, because that disposition is a human judgement about whether a submittal needs review at all.
A run is refused unless the record's currently open step is genuinely the AI pre-review step, so a paid action cannot be fired at a moment where it means nothing.
See Submittal Review for what the review itself does.
Revisions
A revision is a new row, not a new version of the old one. It carries its own number, its own workflow, and its own review history, linked to its predecessor. The predecessor is touched in exactly two places: it is marked superseded, and it stops being the current revision. Its steps, responses, and ball-in-court intervals are never modified again.
Carried forward: everything that describes what is being submitted (spec section, title, description, type, contractor, package, cost code, location, linked drawings, distribution, and the schedule and lead-time fields) plus the review workflow template, so revision 1 goes to the same reviewers without anyone re-picking them.
Not carried forward: the attachments (a revision is a new package of documents, which is the entire point), the AI review, the decisions, and the ball-in-court history.
The register hides superseded rows by default, so the log reads the same as it always did. Turn them on with the superseded filter when you need the chain.
Packages
Packages groups the register by the package name or id carried on each submittal.
A package is a grouping, not a record. There is no package table, no package lifecycle, and nothing to create or delete: the grouping is computed in the browser from the same register read the Log view uses.
Two consequences worth knowing:
- The Packages view reads one page of up to 200 rows and does not follow the cursor, because grouping is only meaningful over the whole set. On a project past that ceiling the view shows a warning band saying the grouping is partial and pointing you at the log's filters.
- Rows logged before package ids existed carry a package name only. Those group by name, case- and whitespace-insensitively, and their cards carry a note instead of the filter and transmittal actions, because a server filter built from a name would match nothing and return the entire log.
Rows with neither a package id nor a name land in a single No package bucket, which always sorts last.
Attachments
Attachments are references to files that already live in the project, with a display snapshot stored on the row. Each is tagged by which side of the exchange it came from, submission or response.
The upload dialog on this register accepts PDF only. A submittal carries at most 50 attachments.
Export
Submittal log downloads the register as a PDF and CSV downloads it as a spreadsheet. Both apply the same filters the register is showing. Private records you are not a party to are dropped from the export for the same reason they are dropped from the register.
Past the read ceiling the export is served short: the PDF prints a visible warning band and the CSV is short. There is also a submittal response-times report in Reports.
Limits
| Limit | Value |
|---|---|
| Submittals read per project | 5,000 |
| Register page size | 200 maximum |
| Attachments per submittal | 50 |
| Company aliases per status | 12 |
| Title | 300 characters |
| Description | 8,000 characters |
| Upload file type | PDF only |
Troubleshooting
"Submittal not found" on a record you know exists. It is private and you are not a party to it. Private records answer 404 rather than 403 on purpose. Ask an admin, or ask to be added to the distribution.
A status is showing a name you do not recognise. The project has company aliases configured. The first alias for a status is its display label; the underlying status is unchanged, and both the alias and the built-in name resolve in search.
The AI pre-review will not run. The record's open step is not the AI pre-review step. The message names the actual state, so you can tell "not sent out yet" from "already past that step". A zero credit balance also blocks it; nothing else in this register is affected by that.
A submittal disappeared from the register after a revision. It was superseded. The register hides superseded rows by default. Turn on the superseded filter to see the whole chain.
The Packages view says the grouping is partial. The project holds more submittals than one read returns, so the cards do not cover the whole job. Narrow with a filter on the Log tab first.
A package card has no filter link. That group was derived from a typed package name with no id behind it. Filtering the server by a name would return the entire log, so the card says so instead of offering a link that looks like it worked.
Rejected and Revise and Resubmit still show actions. That is correct. Both are closed to reviewers but the manager can still resume the review, spin a revision, or void the record.