How to show submittal history on a cover page

Plenty of EPC specifications ask for it: every document arrives under a cover sheet, and the cover sheet carries the document’s submittal history. Every issue, with its date, its submittal number, its issue purpose, and the status that came back. The reviewer sees where the document has been before they read a line of it.

The data isn’t the problem. You already keep it in your register, because it’s the same information as your SDI. The problem is getting it onto a few hundred cover pages and keeping it true. Here’s the method that works if you’re doing it with Excel and Acrobat, and where it stops working.

The manual method

Keep the history in the register, one column group per issue. Your register has a row per document. Add repeating column groups: Sub 1 date, Sub 1 number, Sub 1 purpose, Sub 1 status, then the same four for Sub 2, Sub 3, and so on. Decide up front how many issues you’ll allow for, because your merge template needs a slot for the longest history on the project, not the average one.

Build the cover page as a mail-merge template. Take the customer’s cover sheet format, rebuild it in Word or Excel, and map merge fields to your register columns. The history block is a fixed table with one row per column group. Rows with no data need to collapse or sit empty, whichever the customer’s format tolerates.

Merge to PDF, then bind each cover to its document. Run the merge, get one cover page per document, and combine each cover with its drawing or report in Acrobat. File names need to follow the customer’s convention, so renaming is part of the run.

Re-run at every issue. This is the part people underestimate. The history block has to be true on the day the submittal goes out. A return that landed yesterday belongs on today’s cover page. So the covers you generated last week are already wrong, and every resubmittal means regenerating the covers for every document in it, re-binding, and re-naming.

Done carefully, this works. Suppliers run projects this way. It costs a few minutes per document per issue, which is fine at twenty documents and a different thing at two hundred.

Where it breaks

Four places, in the order you’ll hit them.

The block grows sideways. Document 118 goes to its fifth issue and your template only has four column groups. Now you’re editing the template mid-project, and every previously generated cover no longer matches it.

Staleness. The merge is only right at the moment you run it. Any gap between generating covers and sending the submittal is a window for the history to be wrong, and reviewers notice a cover sheet that omits the return they themselves sent.

The awkward documents. Multi-page cover formats with different data on each page, tag lists that overflow the cell, and manufacturer files that arrive locked and refuse to merge. Each one falls out of the process and gets handled on its own.

The person. The whole method depends on one person running it in the right order under deadline. Their holiday is a project risk.

Where DocBoss comes in

In DocBoss the history block on the cover page is filled from the document’s own record, every send and every return with the dates and statuses that actually happened, and the cover page is generated at the moment the submittal is built. So it can’t be stale and it can’t drift from the register, because it isn’t a copy of the register. The layout is yours to set against the customer’s format, including cover sheets that run to several pages with different data on each, and locked manufacturer files still get their cover pages and footers. The work stops scaling with the document count: filling a form is the same job at document one and document nine hundred.

If you’re running the Excel version of this today, a demo against one of your own cover sheet formats will show you the difference quickly.