The submittal log is a schedule document, not a filing cabinet

Four of our trade pages describe the same bottleneck, and each one describes it as the thing that controls the job.

Millwork, flatly: Shop drawing approval is the schedule, and it is not on your schedule. The paragraph under it is the whole problem in six sentences. You draw, you submit, the architect comments, you revise, you resubmit. Each cycle is weeks and there is no limit on how many there are. Meanwhile your shop capacity for that window is sold and cannot be sold twice, and the GC’s schedule still has your installation starting on the original date.

Doors, frames and hardware: Approval gates a lead time measured in months. And the detail that makes it expensive — One hardware set revised in review can change forty openings, and the order clock starts over.

Structural steel: Approvals gate the mill order, so a slow RFI moves the whole job. Masonry: The mock-up panel holds up the whole order.

Here is the uncomfortable shape of it. On most of your job, the long pole is held by you or by your GC. On the submittal, the long pole is held by a design professional with no commercial interest in your shop calendar, and no contract with you at all.

You cannot make them faster. You can make the record undeniable. That is what a submittal log is for, and it is the reason a log is a schedule document and not a drawer.

Three dates, and the gap between two of them

A submittal log that only records what you sent is a filing system. A log that records three dates is an instrument.

Submitted. The day the package left your office. Not the day you started it, not the day you think you sent it. The day it went.

Required. The day you need it back to hold your order date. This is the date most subs never write down, and it is the one that makes the log useful before the fact rather than after. Work backward: installation start, minus shop time, minus shipping, minus the manufacturing lead time, minus a margin. That is your required-by date, and it is usually far earlier than anybody expects. SubMark’s package has no field for it yet, so write it in the package notes or keep it on your look-ahead.

Approved. The day it actually came back.

The gap between submitted and approved is the number nobody on your job has. Without it, a schedule conversation is two people trading impressions. With it, you can say: nine packages, average twenty-four days in review, three of them on the second revision, and your two-week look-ahead still shows us starting on the fifth. That sentence either moves the schedule or it does not, but it is a conversation nobody can wave off.

Documenting a delay covers the wider version of this argument. The submittal log is the cleanest evidence inside it, because the dates are not disputed — both parties were on the email.

What a package actually is

In SubMark, a submittal package is a project-level record with a number and a list of items.

The number is assigned automatically and it stays with the subject matter, not the attempt. That distinction matters in a minute.

The items come out of a material library that belongs to your company rather than to one job. Each item sits in a subcategory under a category, and carries a manufacturer brand, a size, a material type and its own PDF — the cut sheet, the product data, the test report. You build the library once, on real jobs, and the second time a specification calls for the same hollow metal frame or the same acoustic tile, the item is already there with its data attached.

That is the part that compounds. A submittal log pays you back on job four, not job one. Items are reorderable inside a package and each one can carry its own remark, so the exceptions a reviewer needs to see are attached to the thing they are about.

The package itself carries a title and the spec section it answers, plus who it went to, recorded as free text — the GC, the architect, the owner’s rep, whoever is actually receiving it on this job. And a status.

The status set, and why approved is the end of the line

Five statuses: draft, submitted, approved, rejected, resubmit required.

The status buttons allow two moves. A draft can be submitted. A submitted package can come back approved, rejected, or resubmit required. The one shortcut is the stamped PDF: uploading it marks the package approved from any status, because the stamp is the evidence. You cannot walk an approved package backward, and a rejection is answered with a revision, not an edit.

That looks restrictive until you see what it buys. A status history that cannot be edited into a tidier shape is worth something later. If the question in month fourteen is when did we first submit the hardware schedule and what came back, the answer is a record, not a reconstruction.

So how do you handle a rejection? Not by editing it. You revise it.

A revision is a new package with the same number

When a package comes back rejected or resubmit required — and only then — you create a revision. SubMark builds a new package that:

• keeps the same submittal number,
• increments the revision number,
• chains to the package it came from,
• carries forward the title, the spec section, who it goes to, and the notes,
• clones the item list, so you edit the two items that changed instead of rebuilding twenty-eight, and
• deliberately does not carry the approved PDF across, because a revision is not approved.

The result is a chain: submittal 014 revision 0, rejected; revision 1, resubmit required; revision 2, approved. With dates on each.

That chain is the argument. We submitted in March is a memory. Revision 2 of 014, submitted March 4, returned April 1, revision 3 submitted April 9, approved May 22 is a fact pattern. If the hardware set that changed forty openings is going to cost you a resequence, the revision chain is where the cost came from.

Whether any of that is recoverable depends entirely on your subcontract, and that is a question for your attorney. What is certainly recoverable is the shop capacity you can still re-sell if you see the delay coming in week two instead of week nine.

The cover sheet and the one-file export

Two outputs, and they are the reason the log gets used rather than abandoned.

A cover sheet, generated as a PDF with your company’s logo and document color, listing the items grouped by subcategory. It looks like your company sent it, because it did.

A merged PDF, which is the cover sheet followed by every item’s own PDF, in order, as a single file. One attachment goes to the GC. Not a cover letter plus eleven cut sheets plus a zip file that their email strips.

This is a small thing that changes behavior. The reason people submit badly is that assembling a package properly takes forty minutes of fighting a PDF tool. When assembling it takes the time it takes to pick the items, packages go out complete, and a complete package gives the reviewer one less reason to send it back.

The approval comes back as a stamped PDF, and that is the filing

The reviewer sends back a PDF with a stamp on it. In SubMark you upload that file onto the package — PDFs only, up to 25 MB — and that act is the approval. It sets the package to approved and stamps the approved date for you, so the one date you were most likely to forget gets recorded by the thing you were going to do anyway.

Now the approved submittal is attached to the job rather than to one person’s mailbox. Which matters sooner than you think. Approved submittals are part of the O&M package at closeout, and they are the first thing anybody asks for when a warranty callback arrives a year after that — because the stamped set is what shows that what you installed is what was approved.

Letting a lower-tier sub see the approved set

If you hire subs and invite them into a project, the invite includes a read-only right to view approved submittals — ticked by default on a new invite, and you can untick it. The list is filtered to approved packages on the server, so the grant cannot expose a draft, a rejection or a resubmit — not through the interface and not by guessing a URL.

That is a narrow permission on purpose. Your installer needs the approved hardware schedule. Your installer does not need to see that the architect rejected revision 0.

The honest limits

Be clear about what this is not, because a submittal log oversold is a submittal log abandoned.

• It does not transmit anything to a GC’s system. No Procore or Autodesk submittal integration, no portal push. You build the package, export the PDF, and send it the way you send things today. The approval comes back as a stamped PDF you upload. If your GC requires submission through their platform, you will still do that — the log is your record of it, not a replacement for it. Procore for subcontractors covers that split.
• There is no ball-in-court workflow and no reviewer routing. SubMark does not know who has it next, because SubMark has no relationship with the architect.
• There is no required-by field. The package records submitted and approved dates; the date you need it back lives in the package notes or your look-ahead, and nothing warns you when it passes. The honest claim is that the dates you do have are on the log and the log is on the job, where the PM can see them — not that the software will chase anything for you.
• Lead times are not calculated. Your supplier’s quote tells you the lead time. The log is where you record what you did about it.

What to do on your next job

1. Build the submittal list in the first week, from the specification, before anybody asks for one. Nearly every SubMark trade setup pack opens its pre-construction items with a version of confirm the approved _____: the fixture, panel and device schedules for electrical; the equipment submittals and lead times against the schedule for HVAC; the shop drawings and the current revision for structural steel; the shop drawings, glass makeup and finish for glazing; the door, frame and hardware schedules and the keying for doors and hardware; the shop drawings and finish samples for cabinetry. It is item one because nothing else can move until it is done.
2. Work out a required-by date for every package, backward from installation, and write it in the package notes. Even a rough one beats none.
3. Mark the package submitted the day it goes, every time — that stamps the submitted date. This is the whole discipline, and it is twenty seconds.
4. When something comes back marked up, revise it rather than overwriting it. The chain is the asset.
5. File the stamped approval onto the package, not into your email.
6. In the first week of every month, read the log as a list of open packages against their required-by dates. That is the earliest place your schedule risk is visible.

Submittals are on by default in all 29 trade setup packs — every commercial trade submits — so unless someone has switched it off in your trade configuration, your SubMark projects already have the log. See where it fits on the product page, and pricing is one place: every plan includes the full module set.

The approval date is the one date on your job you do not control. That is exactly why it is the one you should be able to prove.

This article describes operational practice, not legal advice. Whether a review delay is recoverable depends on your subcontract and your state’s law. Ask your attorney.