A submittal log has more structure to it than most sites use. Procore's own version tracks fifteen distinct columns, and the log that actually stays current is usually the one built around a single one of them: who is holding the ball right now.
Key takeaways
A submittal log exists to organize documentation — shop drawings, product data, catalog pages, all filed against a spec section — and to answer, at any point, who currently needs to act. That second part is the one that actually decides whether the log stays useful past the first week of a job.
Procore's own column list runs to fifteen fields, and it is worth naming a few that carry more weight than they get credit for: “Spec Section” — “the corresponding section from the project's specifications book”, “Ball In Court” — “the name of the person responsible for completing the next action”, and “Due Date” — “the date on which response(s) to the submittal are due from the approvers”.
That due date does not have to be a fixed calendar entry either. Procore documents an optional Dynamic Due Dates configuration that, in its own description, defines workflow step durations instead of fixed due dates, so each step and role keeps its own contractually obligated response window; as steps complete, the next step’s due date automatically adjusts forward or backward to comply with the defined durations. A log built on a duration that recalculates, rather than a date someone typed once at kickoff, does not go stale the first time a review runs three days over.
Almost every submittal log has a status column and a responsible-contractor column. Fewer actually use “Ball In Court” the way it's defined — “the name of the person responsible for completing the next action,” a named individual, not a company. A log that says a submittal's status is “with the mechanical sub” is not answerable; a log that names the specific reviewer at the specific firm is.
That distinction is the difference between a log that can be chased and one that can only be complained about. A status of “pending review” with no named person attached produces a phone call to a company switchboard; a named ball-in-court produces a direct follow-up to the one person actually holding it.
A “Submittal Builder” feature can “generate submittals from specifications,” which means the log's starting structure comes directly from the spec book rather than someone manually transcribing a submittal register from a PDF into a spreadsheet. That connection is the tool's own design — the log and the source document describing what needs to be submitted are meant to be the same living structure, not two things a coordinator keeps synchronized by hand.
Building the log this way also makes gaps visible early: a spec section with no corresponding submittal entry is a missing submittal, not a silent one, which is a materially different problem to catch in week two of a job than to discover at closeout.
Bluebeam's interactive stamps let a reviewer place a mark that captures “Submittal status, Reviewer, Date, Submittal number, Spec number” directly on the reviewed drawing. That keeps the status decision attached to the actual reviewed document at the moment it was made, rather than as a separate note someone has to remember to update in a spreadsheet afterward.
The failure mode this avoids is a log that says one thing and a marked-up drawing set that says another, because two people updated two different records of the same review at two different times. One stamped event, feeding one log entry, closes that gap.
A glossary entry on the submittal register itself and one on shop drawing review stamps cover the vocabulary in more depth; a log built well from the start is also the difference between a healthy queue and a backlog that needs actively clearing once volume picks up.
A submittal log with fifteen well-designed columns still fails if nobody is responsible for keeping it current. The usual failure isn't a missing field, it's that several people can update the log and none of them is specifically accountable for it, so entries get created promptly and then quietly stop being maintained once the person who set them up moves on to the next task.
Assigning ownership of the log itself — not every individual submittal, just the log's overall currency — to one coordinator is a small role most jobs can absorb into an existing position. That person's job is narrow: confirm ball-in-court and due-date fields are current on a fixed cadence, not personally chase every open item. The chasing still belongs to whoever the log says is holding it; the coordinator's job is making sure the log is telling the truth about who that is.
A short, fixed cadence works better here than an open-ended commitment to keep it current. Once a week, a coordinator scanning for stale due dates and unnamed ball-in-court entries catches drift while it's a handful of items, rather than discovering at closeout that half the log went unmaintained for months.
A worked example
Say a submittal log carries 60 open items on a mid-size job, and roughly a third of them list a responsible company but no named ball-in-court individual. Chasing those 20 items means a phone call or email to a switchboard, a wait for someone internally to route it, and a second follow-up before the actual reviewer is even identified — call it two extra days of latency per item versus a log with a named person attached from the start.
Across 20 items, that is roughly 40 days of collective latency sitting in the gap between “assigned to a company” and “assigned to a person” — not 40 calendar days on the critical path, since items run in parallel, but 40 days of someone's time spent chasing a name the log should already have had. These figures are illustrative; the real cost depends on how many open items a specific log is actually carrying at once.
It names the specific person responsible for the next action, not a company or trade. Procore's own definition is “the name of the person responsible for completing the next action” — a log that only records a responsible firm is missing the field that actually makes an item chaseable.
Yes — a Submittal Builder feature can “generate submittals from specifications,” populating the log from spec sections directly rather than requiring someone to manually re-key a submittal register from the spec book.
An interactive stamp applied to the reviewed document itself, capturing status, reviewer, date, submittal number and spec number in one place, keeps the mark-up and the log record tied to the same event rather than two separately updated records that can drift apart.
A 30-minute call is enough to tell you whether AI pays for itself here.
