Reading time: 6 min
A folder that holds several copies of one file, each labeled with some variation of "Final," signals a version problem. Nobody on the team can say with confidence which copy is current or who changed it last. People edit the wrong file and lose time comparing documents line by line.
Version control solves this with two tools that work together. The first is the version history built into your cloud storage platform or office suite, which records every save automatically. The second is a version table that sits inside the document itself and records the meaning behind each change.
This article walks you through both. You finish with one current copy of each file and a version table in every long-lived document your business relies on.
Before You Start
You need a few things in place before you begin.
- Access to the shared drive or cloud storage platform where your working files live
- Edit permission on the documents you plan to clean up
- A list of documents that stay in use for more than a few weeks
- A decision on who maintains the version table in each document
- Your file naming conventions, if your business has them
- About 15 to 30 minutes per folder for the first cleanup
The Process
The steps below move from cleaning up existing copies to building a habit that keeps every file current.
Step 1. Duplicate File Cleanup
You open the folder and sort the files by name so that similar titles group together. Clusters of files with suffixes like these point to a version problem:
- "Final"
- "Final v2"
- "Final REAL"
- "Copy of"
You compare the copies in each cluster and identify the one that holds the latest approved content. That copy keeps the plain document name, without a suffix. The other copies move to an archive subfolder, where they stay until you confirm that the current file contains everything it needs.
Step 2. The Platform's Version History
Your cloud storage platform or office suite keeps a version history for each file. The feature usually sits in the file menu or appears when you right-click the file in the shared drive, under a label such as "Version history." The history shows three pieces of information for every saved version:
- Who updated the file
- When the update happened
- What changed between versions
You can open any earlier version and restore it when needed. This feature replaces the habit of saving a new copy each time the document changes. One file, saved in place, carries its own history.
Step 3. One File, Saved in Place
The team agrees that each document exists as a single file. Everyone edits that file directly rather than saving a renamed copy. The platform's version history captures each save, so the file name stays the same from the first draft through the approved version.
Your file naming convention handles the rest. A clear name describes the document's content and purpose, and the version history handles the timeline. Status words such as "Final" or "Draft" stay out of the file name because the history and the version table carry that information.
Step 4. Long-Lived Document Selection
Built-in history captures every save, but it does not explain why a change was made. Some documents need that explanation. You add a version table to three document types:
- Project documentation that takes months to build. A template started on October 1 may not be complete until the project goes live in February.
- Living documents that are updated constantly, such as a procedures manual or a price list.
- Templates that get revised as circumstances change.
You review your list of documents from the Before You Start section and mark each one that fits a category. Short-lived files, such as a one-time meeting agenda, rely on the built-in history alone.
Step 5. The Version Table
The version table sits inside the document, usually right after the title, where readers find it quickly. It has three columns:
- Date Updated
- Updated By
- Updates Made
The Updates Made column carries the most value. A useful entry names what changed and why. An entry reading "Revised" tells a reader very little. An entry reading "Added the spring pricing tier per owner approval" tells the reader what to look for and the reason behind it.
The first row records the document's creation. Each later row records one round of changes, with the newest entry at the top or the bottom, whichever your team prefers. Consistency across documents matters more than the direction you choose.
Step 6. Two Records Working Together
The built-in history and the version table do different jobs. The built-in history captures every save automatically. The version table captures meaning: what changed and why it matters.
A reader who needs to recover a deleted paragraph uses the version history. A reader who needs to understand how a policy evolved over six months reads the version table. Neither record replaces the other, and together they give you a complete trail for documents that change over long periods.
Step 7. An Entry for Every Change
The version table works only when someone fills it in every time the document changes. Entries written at the end of the week rely on memory, and a skipped entry breaks the trail. The person who makes the change adds the row before closing the file.
You can build this into the team's routine by placing a short reminder line under the table, such as "Add a row each time you edit this document." New contributors see the expectation the first time they open the file.
Worked Example
Bright Circuits Youth Lab, a youth STEM nonprofit, runs after-school robotics programs at four schools. The program coordinator, Dana Reyes, found a shared folder holding these files for the volunteer handbook:
- Volunteer Handbook Final
- Volunteer Handbook Final v2
- Volunteer Handbook Final REAL
- Copy of Volunteer Handbook Final v2
Dana compared the four copies and confirmed that "Final REAL" held the board-approved content. She renamed it "Volunteer Handbook" and moved the other three files into an archive subfolder. A check of the platform's version history showed that the executive director, Marcus Hale, had made the last edit on September 22, 2026.
The handbook is a living document, so Dana added a version table directly under the title. She also started a version table in the new Spring Program Plan, a project document the team began on October 1 and expects to finish when the spring program goes live in February. She placed a reminder line under each table.
A volunteer asked two weeks later why the background check deadline had moved. Marcus answered by pointing to the October 14 row in the handbook's version table. The answer took less than a minute.
Checking Your Work
You use this checklist to confirm the system is in place.
- Each document exists as one file with a plain, descriptive name.
- No file name carries a status suffix such as "Final" or "v2."
- Older duplicates sit in an archive subfolder.
- Every long-lived document has a version table near the title.
- Each table uses the three columns described in Step 5.
- Each Updates Made entry states what changed and why.
- The latest table entry matches the latest date in the platform's version history.
- A reminder line sits under each version table.
