# Your Cut Sheet Library Is Quietly Going Stale: Keeping Datasheets Current Across Jobs Last job's datasheet is how a stale revision or a file that won't open ends up in this job's package. Keep one current sheet per part and check it first. A datasheet you reused from the last job can be a revision behind, describe a model the manufacturer renamed, or not open at all, and you usually find out at compile or at review. Keep one current datasheet and manual per part instead of a copy in every job folder, check each file before the package is built, and know which revision went out on which submittal. It's 4:30 on Friday and the package is due. You grab the transmitter datasheet from the last job's folder, because it's the same transmitter. The merge chokes on it. You go to the manufacturer's site for a fresh copy and the link from last year lands on their home page. Twenty minutes later you have a datasheet, and it isn't the one you sent last time: the model got a new name, the ordering table moved, and the option code you highlighted is gone. None of that is the reviewer's fault or yours. Manufacturer literature moves on whether your folders keep up or not. The fix is to stop treating each job folder as its own library. ## Why the datasheet you saved is already out of date Manufacturer PDFs drift in a few predictable ways: - **Revisions.** The manufacturer corrects a rating, adds a listing, or drops an option, and publishes a new revision under the same file name. Your saved copy doesn't know. - **Renamed and replaced models.** A product line gets rebranded after an acquisition, or a model goes end of life with a named successor. Last job's sheet still describes the old one, and a reviewer who checks the manufacturer's site will see it. - **Dead links.** Literature libraries get reorganized, and a download link you bookmarked starts landing on a search page or a login wall. - **Files that won't open.** A half-finished download, a password-protected PDF, or a "PDF" that is really the login page someone saved with a .pdf name. It looks fine in the folder. It fails when something tries to read it. Every one of those is invisible until someone opens the file for real. Too often that someone is the merge at 4:30, or the engineer. ## One part, one current datasheet A copy of the datasheet in every job folder means every job has its own idea of which revision is current. Six jobs later you have six copies, and nobody knows which one was corrected. Attach the datasheet and the O&M manual to the part instead, once, and have every job point at that part. When the manufacturer revises the sheet, you replace it in one place and the next package picks it up. The groundwork for that is in [building a reusable parts library](/learn/reusable-parts-library). Then make "is this still current?" a habit at the moment you reuse a part, not a cleanup project: - **Read the revision on the sheet.** Most manufacturer datasheets print a revision letter or a publication date in the footer or on the back page. Compare it with what the manufacturer offers today. - **Check the catalog number still prints.** If the ordering page no longer builds your exact code, the model changed or your copy is for the wrong variant. Either way, [the options are where compliance lives](/learn/catalog-number-highlighting). - **Look for a successor notice.** An end of life part on a new package is a comment waiting to happen. Name the replacement before the engineer asks. ## Open every file before you build the package The cheapest moment to find a bad file is Tuesday, when you pick the part, not Friday, when you're compiling. Before the package gets built, open every document going into it: - It opens, all the way to the last page, without a password prompt. - It's the document it claims to be: a datasheet, not a quote, a login page, or a different product in the same family. - It prints the catalog number you're submitting, or the family code your ordering table builds from. That pass takes minutes per package. Finding the same problem in the merge costs you the evening, and finding it in review costs you a cycle. ## Know which revision went out on which submittal Here's the stale datasheet nobody sees coming. Rev 0 went out with the old transmitter sheet. The engineer commented on it. You fixed it, but the fix went into the job folder, not the original. Now Rev 1 gets built from a different folder, and the old sheet comes back with the same problem the engineer already flagged. Two habits stop that: - **Keep what you issued frozen.** The package that went out is the record of what the engineer reviewed. Don't edit it, overwrite it, or "fix" it after the fact. Fix the working copy and issue a new revision. - **List what changed between revisions.** When a datasheet is replaced on a resubmittal, say so on the transmittal or in your comment responses. The engineer reviews Rev 1 against their comments, and a replaced document they didn't hear about is one more thing to hunt for. The full method is in [answering review comments on a resubmittal](/learn/answering-review-comments). ## How Submittal Kit handles this You'd rather spend Friday afternoon sending the package than chasing a PDF. In Submittal Kit every datasheet and manual lives on the part in a shared Parts Library, and every project's equipment points at that part, so replacing a sheet once updates every job that uses it. Re-download a sheet you already have and it's flagged as a **Possible duplicate** instead of becoming a second copy. On a part's page, the **Find documents** panel names the revision each attached document prints, such as "On this part: Datasheet, Rev C." Matches from your library and from the web each show the revision date the file prints, and web finds rank the ones that print your catalog number, come from the manufacturer's site, and carry the newest revision first. **Search again** reruns the hunt after a vendor publishes the revision you were waiting for, and nothing enters your library until you press **Add**. Replace a part's datasheet and any compiled package that used the old one says "Equipment changed since this was compiled. Recompile before submitting." The **Checks** tab flags an item with no document, a datasheet that never prints the part's catalog number, and a part the distributor lists as obsolete or end of life, with its suggested replacement. A file missing from storage is named before you compile, with **Go to the item**, and a file that won't open stops the compile with nothing issued. Opening each file to confirm it's the right document is still yours. Issued submissions keep the exact bytes you sent, no matter what changes later, and the **Since** line on each one lists the documents it added, replaced, or removed compared with the submission before it. See [Find Datasheets](/help/find-datasheets), [Part Documents](/help/part-documents), [Compile a Submittal](/help/compile-a-submittal), and [Returned reviews](/help/returned-reviews). *Disclosure: I build [Submittal Kit](/), and every habit above works with a folder per part and the discipline to replace one file instead of six.* --- Submittal Kit · Field Guides · Updated 2026-10-31 Canonical: https://submittalkit.com/learn/keep-datasheets-current