Building the document list from the equipment list

Carl Mueller
September 15, 2026
2 min read
Building the document list from the equipment listBuilding the document list from the equipment listBuilding the document list from the equipment listBuilding the document list from the equipment listBuilding the document list from the equipment listBuilding the document list from the equipment listBuilding the document list from the equipment list
Blog

At the start of a new order, someone opens a spreadsheet and starts typing the list of documents the order owes: drawings, datasheets, test reports, manuals, each against the equipment it belongs to. On an order with many tags keeping that straight is the fiddly part, and it does not stay finished either, because tags get added, models change, and every change order reopens the typing.

Here is the thing about valve and instrument work specifically: that list is largely derivable already, implied by data you have.

Your equipment list says what you are supplying: the tags, the models, the assemblies, the valve with its actuator and positioner on the same line. Alongside it, your customer’s document codes say what types of document each kind of equipment owes. Cross the two and the document list falls out. A control valve tag owes a datasheet and a stroke test because the codes say those document types apply to that equipment.

Define the rule once, apply it across the equipment, and the list follows from the data rather than from what anyone has to remember.

The follow-on advantages are bigger than the first pass. When tags are added mid-job, the rule already knows what they owe, so each new tag brings its expected documents with it. When the customer never sent document codes at all, which happens, the same rule runs on your own internal codes, so the list exists anyway and stays comparable across projects whatever each customer calls things.

This is the job DocBoss was originally built around. You load the equipment list the way it already exists, whether that is the quotation team’s list or an ERP export, and DocBoss combines it with the document codes to create a placeholder for every expected document before any file is produced. Every placeholder is linked to its equipment, so tag data flows onto cover pages and outputs instead of being typed again. Tags added later are picked up the same way, and a change order that voids or supersedes documents is handled as a change to the list rather than a re-type of it.

The document list is the foundation the rest of the project stands on: the submittals, the tracking, the expediting and the final databook all read from it. Build it from the equipment data and it exists before the first file does, and it keeps up as the order changes.

Ready to leave the
clerical grind behind?

Related Resources