Quality & Safety
Where it lives
Project

Submittals

A submittal is the formal loop where the contractor proves that what they intend to build matches what was specified: shop drawings, product data, samples, mock-ups, certificates. Somebody submits, somebody reviews, and the answer comes back stamped. The specification decides what has to go round that loop; this tool tracks each one through it.

The reason it needs a tool of its own rather than a folder is timing. A submittal that takes three weeks to come back on an item with an eight-week lead time has already cost you a week on site, and nobody notices until the delivery is late.

The register

The register opens on four views.

Items is every submittal. Packages groups related ones, so a Structural Steel package can be looked at as one thing while the connections, the coatings and the mill certificates stay separate records inside it. A package has no status of its own: it shows the state of what is in it, which is the only honest answer.

Spec Sections organises submittals against the specification's own numbering, so "05 12 00 Structural Steel" is the same reference here as it is in the spec book.

Action Required is the short list of what is waiting on you, and it carries a red dot when it is not empty. The same count sits on the Submittals item in the sidebar, and the items themselves also appear in My Items.

Raising one

Choose New Submittal. The record carries a title and a description, its type (shop drawing, sample, product data and so on), the package and spec section it belongs to, and the location if it is tied to one.

Then the two sides of who: the responsible organisation, the contractor whose submittal it is, and the submittal manager, the person on your side steering it through, which defaults to whoever created it.

Then the dates, which are the reason for the tool. Submit by, final due, the lead time in days and the required on site date, and, once things are moving, the anticipated, confirmed and actual delivery dates. Those together are what let the register answer whether a review that has not come back yet is going to hurt.

A submittal can be marked private, which limits it to the submittal manager and the distribution list. Use it sparingly: a private submittal is invisible to the people who would otherwise have chased it.

Where a specification has produced a hundred submittals before anybody has drawn anything, they can be brought in from a CSV rather than typed in one at a time.

Review and stamps

Submitting starts the review. A reviewer returns one of the outcomes the project has configured as review stamps, which are named and coloured in tool settings: the usual set is approved, approved as noted, revise and resubmit, and rejected, but the names are yours.

The status vocabulary behind them runs draft, open, submitted, under review, approved, approved as noted, revise and resubmit, rejected, closed, void and superseded.

Approved as noted

The outcome most often misread, so it is worth being clear. Approved as noted means proceed, working to the comments marked on the returned document, with no further submission required.

It is not a soft rejection and it is not a request to resubmit. Treating it as one is how a project ends up spending a fortnight on a second round nobody asked for, and how a fabricator ends up waiting for an approval they already have.

Revisions

Here is the part that is different from most review loops in Teralo, and worth getting right before you go looking for a resubmit button.

A revision is a new record, not a new round on the old one. When a submittal comes back as revise and resubmit, that submittal is finished: its review has ended with an answer. Creating a revision mints a fresh submittal that keeps the same submittal number, increments the revision, and links back to the one it came from.

So SD-014 revision 0 was rejected and SD-014 revision 1 is the new attempt, both of them permanent records with their own reviews, their own dates and their own comments. The chain is the history, and you can read straight down it to see what was asked for and what changed. The alternative, a single record that goes round twice, loses exactly the thing an argument about delay is about.

SettingsHost only

Tools, then Submittals holds four things, all of them written at organisation level and activated per project:

  • Submittal types, the kinds of submission your specifications ask for
  • Spec sections, the industry numbering your projects are written against
  • Review stamps, the outcomes a reviewer can return, with their names and colours
  • The workflow bound to each type

The activation step matters here more than in most tools, because a full spec section list is hundreds of entries and no single project uses all of them. Write them once, switch on the ones the job needs. See Organisation level and project level and The tools catalogue.

PermissionsHost only

  • Can view submittals and packages shows the register
  • Can create submittals and packages allows raising them
  • Can review and approve submittals in workflows is the reviewer's permission
  • Can manage all submittals allows editing, reassigning and configuring the tool, and acting at any step
  • Can permanently delete submittals is separate and not implied by managing

The review permission is the one to place carefully, because it is the specification being enforced. A manager can act on any step of any submittal; a reviewer acts on the reviews they are a participant in. See How permissions work.

WorkflowsHost only

The workflow is bound per submittal type, and it starts at submission rather than at creation, so a draft carries no run.

An individual submittal can override the type's workflow where the type has not been locked, which is the escape hatch for the one item that needs the engineer as well as the architect without inventing a type for it.

Because a revision is a new record, the graph is a straight run to an outcome with no loop back: revise and resubmit and rejected both END the run. That is deliberate, and it is why there is no Task node in the default shape. Build variations in the workflow builder and attach them as described in Binding a workflow to a tool.