# Building a Reusable Parts Library So You Stop Rebuilding Packages Why an integrator's document work repeats across every job, and how a maintained parts library turns package assembly from research into retrieval. Look at your last five submittal packages. How many catalog numbers appear in more than one of them? For most integrators the honest answer is "most of them." The same PLC line, the same relays, the same terminal blocks, power supplies, and Ethernet switches, job after job. Now the uncomfortable follow-up: how many times did someone go find the datasheet for that same relay? If the answer is five, you're paying for the same hour repeatedly, and the fifth copy is probably a different revision than the first, which is its own problem. A parts library is the fix, and it's less a tool than a discipline: **one company-wide list of the parts you actually use, with the right document attached to each, maintained as an asset instead of recreated as an errand.** ## What a part needs to carry Keep the record boring and complete: - **Manufacturer and complete catalog number.** The full orderable string, options included, because [the options are where compliance lives](/learn/catalog-number-highlighting). If you supply two variants, that's two parts, not one part with a mental asterisk. - **A one-line description in your own words.** "24VDC 10A DIN-rail power supply," not the marketing name. This is what makes the library searchable by a human in a hurry. - **The current datasheet.** The manufacturer's document for that catalog number, the one you'd put in a package tomorrow. - **Certifications where they matter.** The UL listing card or agency documentation for parts whose specs routinely demand it. Chasing a listing certificate once beats chasing it per job. ## The rules that keep it trustworthy A library dies from distrust: the first time someone pulls a datasheet and gets a superseded revision or the wrong variant, they go back to googling, and the library becomes a folder of lies. Four rules prevent that. **One entry per catalog number, no duplicates.** Duplicates split the history and guarantee the two copies drift. If your tooling can detect that two files are byte-identical, so much the better, but the discipline matters more than the mechanism. **The datasheet is attached to the part, not to the project.** Projects reference the library; they don't hold private copies that fork. This is the structural decision everything else hangs on, because it's what makes improvement compound: every markup, correction, and verified detail lands in the one place every future job draws from. **Somebody notices manufacturer revisions.** Datasheets change. The library needs a habit, even a lightweight one, of updating a part's document when the manufacturer revises it, while never disturbing the frozen copies inside already-issued packages. The library is working state; issued revisions are the record. Both matter, and they're different things. **Retire, don't delete.** When a part goes obsolete, mark it discontinued and name the successor. Old projects still reference it, the O&M manual you compiled in 2023 still describes it, and the tech maintaining that system deserves to find it. ## What the library pays back **Package assembly becomes retrieval.** BOM comes in, parts match against the library, datasheets are already attached and already correct. The work that remains is the genuinely per-project part: the [spec compliance check](/learn/read-a-spec-section-for-submittals), the highlighting for this job's tags, the package structure. On a typical package that converts most of a day of hunting into minutes of confirming. **Quality compounds instead of resetting.** The datasheet that got corrected on the last job is the datasheet this job starts from. Without a library, every project's quality starts from zero; with one, your hundredth package is built on ninety-nine packages of accumulated verification. **The O&M manual gets cheap.** The manual needs [the same datasheets organized per panel](/learn/build-a-control-panel-om-manual). If projects reference a library, the manual's product-data sections assemble themselves from decisions already made. **New people become productive faster.** The library encodes "what we use and why" better than any onboarding document. The senior engineer's part preferences stop living exclusively in the senior engineer. ## Starting from a pile of folders Don't schedule a heroic migration; harvest instead. Starting now, every part touched by a live project goes into the library properly: correct catalog number, description, current datasheet. Your next three jobs will populate the couple hundred parts that constitute most of your volume, because the repetition that makes the library valuable is the same repetition that fills it fast. Backfilling the long tail of parts you used once in 2019 can wait forever. The one prerequisite worth enforcing from day one is the no-duplicates rule. A library seeded with four copies of everything never earns the trust that makes people use it. *Disclosure: I build [Submittal Kit](/) around exactly this idea: a shared, deduplicated parts library where documents attach once and every project draws from it. A disciplined folder structure gets you a real fraction of the value; the discipline is the product either way.* --- Submittal Kit · Learn · Updated 2026-08-17 Canonical: https://submittalkit.com/learn/reusable-parts-library