A submittal is how a construction team proves, on paper, that what they are about to install matches what the design called for. Before a subcontractor orders the steel, fabricates the ductwork, or pours the mix, they send documentation — shop drawings, product data, samples, mock-ups — to the design team for review. The architect or engineer checks it against the specification and returns it with an action. This template models that round trip — from Identify submittal item to Distribute & procure — as a living graph you can assign, track, and connect to procurement.
It is built for the people who run the submittal register: the general contractor's project engineers who compile and stamp packages, the subcontractors who prepare them, and the architects and consultants who review them. If you have ever had a long-lead item show up wrong because an approved-as-noted stamp was misread, you already understand why this process deserves to be tracked, not just filed.
The flow has seven steps and one fork. The main path carries a submittal from identification through review to procurement; a single loop sends a rejected or marked-up item back to the subcontractor to fix and resubmit. That loop is the whole reason submittals exist — to catch the problem on paper instead of on the truck.
How this submittal workflow template works
Identify submittal item. The process begins with the submittal register — the list, pulled from the specifications, of every item that requires a submittal. Each spec section names what must be submitted, so this step is about knowing what is due and when, relative to when it needs to be installed.
Subcontractor prepares. The responsible subcontractor assembles the package: shop drawings dimensioned to the actual conditions, manufacturer product data, physical samples, or a mock-up. The quality of preparation here largely determines whether the item sails through review or bounces back.
GC review & stamp. Before anything reaches the design team, the general contractor reviews the package for completeness and coordination and applies its own stamp. This is the contractor certifying that they have checked the submittal against the field and the other trades — it is not a rubber stamp, and skipping it is how uncoordinated packages waste a design review cycle.
Submit to architect. The stamped package is transmitted to the architect of record, logged with a number and a date so its aging is tracked from the moment it lands.
Architect / consultant review. The architect, or the specific consultant who owns that scope — structural, mechanical, electrical — reviews the submittal against the design intent and the specification. They confirm the proposed product or assembly actually meets what was specified.
Returned: approved or revise. This is the fork. The review comes back with an action stamp — typically Approved, Approved as Noted, Revise and Resubmit, or Rejected. An approved or approved-as-noted item moves forward. A revise-and-resubmit or rejected item takes the loop.
The revise-and-resubmit branch. On the graph, the edge labeled revise & resubmit loops from Returned: approved or revise back to Subcontractor prepares. The subcontractor addresses the review comments and starts a new revision — Rev B, Rev C — through the same GC stamp and architect review. Tracking how many times an item loops is one of the clearest early warnings of a coordination problem or a subcontractor who is over their head.
Distribute & procure. An approved submittal is distributed to the field and released for procurement and fabrication. This is the payoff: the approved package becomes the authority to buy and build, and it links directly to the purchase order and the delivery date.
How to use it in FlowGraph
- Open the template. Click Open in FlowGraph to load the submittal workflow as a live graph. Viewing and editing are free with no account, so you can shape the flow to your project before you save anything.
- Log each item. Duplicate the flow per submittal item and set its spec section on the first card. A concrete project has dozens of these; the pattern is the same each time, so the graph becomes your live register rather than a static diagram.
- Mark the review outcome. Record Approved, Approved as Noted, or Revise & Resubmit on the Returned: approved or revise step so the ball-in-court is always clear. Because every edit is governed and carries a receipt, the review history — who stamped what, when — is preserved rather than lost in email.
- Connect procurement. Link an approved submittal to its purchase order so lead time is visible. When you tie the Distribute & procure card to a long-lead item's delivery date, a submittal that is still looping on a critical item surfaces before it quietly consumes the float in your schedule.
- Extend it with AI and your model. With your own AI key you can ask FlowGraph to build the register from a spec table, or to flag which submittals feed long-lead procurement. You can also import an IFC model and link a submittal to the element it will become. The AI proposes; you verify and decide.
Why a living graph beats a static submittal log
A submittal spreadsheet tells you a status and a date. It cannot show you that a still-in-review item sits on the critical path, or that a rejected package is now threatening a pour scheduled in two weeks. Because every card in FlowGraph is a real object linked by typed relationships, you can connect a submittal to its specification, to the model element it becomes, and to the purchase order and lead time behind it — so a late submittal on a long-lead item surfaces before it delays the schedule, not after.
Every change flows through a single governed write path and carries a receipt: who stamped this package, when it was returned, why it looped. That honest, reversible history is exactly what you want when a delivery slips and the question becomes whose delay it was. The record is already there, timestamped, instead of being reconstructed from inboxes.
And the graph is not frozen. Ask AI to extend the workflow with your firm's review gates, replicate the pattern across a whole register, or wire the approved items to a live procurement view — all without leaving the traceable write path underneath. It stays local-first and yours: the template opens with no account, and signing up only enters the picture when you want to save it to a vault or plan with AI.
Frequently asked questions
What is a construction submittal?
A submittal is documentation a subcontractor provides — shop drawings, product data, samples, or mock-ups — to demonstrate that a proposed material or assembly meets the project specification. The architect or engineer reviews it and returns it with an action stamp before the item can be fabricated or installed.
Submittals exist to close the gap between the general language of a specification and the specific product a subcontractor intends to buy. They are the checkpoint where design intent and real-world procurement are reconciled on paper, before money is committed.
What are the submittal review outcomes?
The typical action stamps are Approved, Approved as Noted, Revise and Resubmit, and Rejected. Approved means proceed; approved as noted means proceed while incorporating the reviewer's marks; revise and resubmit and rejected both send the package back for another round.
This template models the approve-or-revise fork directly — the Returned: approved or revise step branches forward to procurement or loops back to the subcontractor, so a resubmittal is a first-class part of the flow rather than an afterthought.
Why track submittals on a graph?
A submittal log that lives as a graph shows the ball-in-court, the aging, and the link to procurement lead times all in one view. You can see which items are stuck in review, how many revisions each has taken, and — most importantly — which of them sit on long-lead materials.
That connected view is what lets a late submittal on a long-lead item surface before it delays the schedule. On a flat spreadsheet those relationships are invisible; on a graph they are the structure itself.