A client sends “final-copy.docx”, then “final-copy-new.docx”, then a correction in an email. Before production, you need to know which document is the working reference and what has actually been approved.
This guide creates a manual version register. It records where each version lives and its review outcome; it does not replace the revision history of the file itself.
What you will build
One Documents database with a record for each version, a current-reference view and a review for missing file links. Use an existing document register if it already serves this purpose.
1. Define the document group
A document group identifies the deliverable across versions, such as Oak website — homepage copy. Use the same group value for its drafts and approved revisions.
For a small register, a Text property called Document Group is enough. Write it consistently. If you already have a document identity database, use its relation instead.
2. Add the version fields
| Property | Type | Purpose |
|---|---|---|
| Document Version | Title | Recognizable document and version name |
| Project | Relation | Existing project record |
| Document Group | Text | Stable identity across versions |
| Version | Text | Source version label |
| File or Link | URL | Exact file reference |
| Review Status | Select | Needs review, Changes requested, Approved or Superseded |
| Current | Checkbox | Working reference for this document group |
This example uses a URL to the file. If your process uses uploads, choose Files & media instead and adapt the missing-reference check.
Connect Project to existing records. Follow how to connect databases if that relation is missing.
3. Record the exact reference
- Create a version record.
- Select its existing project.
- Enter its document group and version label.
- Open the file link and confirm it reaches the intended document.
- Record the source message and review notes in the page body.
A link to a folder is not an exact version reference. A live document URL may also keep changing while the address remains the same. In that case, record the revision identifier or the dated snapshot your workflow uses.
A useful note is “Copy v2 received in the client’s email; sections 1–4 approved, section 5 still requires review.” Preserve the actual source rather than inventing an approval summary.
4. Test three versions
| Version | Review Status | Current | Meaning |
|---|---|---|---|
| v1 | Superseded | Unchecked | Earlier draft retained for reference |
| v2 | Approved | Checked | Approved production reference |
| v3 | Needs review | Unchecked | New draft awaiting a decision |
These are fictional records. The highest version number is not automatically the approved production reference. The new draft does not replace v2 merely because it arrived later.
5. Create two operational views
Create Current references, filtered to Current is checked. Show Project, Document Group, Version, Review Status and File or Link.
Create Approved current references, using Current is checked AND Review Status is Approved. This narrower view excludes working references still under review.
Use the AND and OR filter guide to keep these conditions together.
6. Catch incomplete and conflicting references
Create Missing file references with File or Link is empty. Review the original source before assigning a link.
In Current references, group records by Document Group and inspect each project. If two versions of the same document group are current, resolve that conflict. If none is current, decide whether there is a valid working reference yet.
The checkbox is a manual convention. It does not enforce exactly one current version or automatically identify document groups with no current record. Review the full register when checking for those gaps.
7. Replace the reference after a decision
- Confirm the review outcome for the new version.
- Record the approval source and what it covers.
- Update Review Status.
- If the version should replace the current reference, clear Current on the previous version and check it on the replacement.
- Mark the older version Superseded if it has been replaced.
- Check Current references for the document group.
If the new document changes agreed work, review that decision using the scope-change tracker before updating production tasks.
Common mistakes
- Using “final” as the version identity: preserve a specific label or revision reference.
- Overwriting the old link: keep separate version records when history matters.
- Equating Current with Approved: check both before relying on a production file.
- Leaving two references current: resolve the group rather than expecting a checkbox to enforce uniqueness.
Frequently asked questions
Should each version have its own record?
Yes, in this recipe. Separate records preserve the file reference, review outcome and history of each version.
Does Current mean approved?
No. Current identifies the reference your team should use. Review Status records whether that version has been approved.
Can Notion verify that a file is the latest version?
This manual workflow cannot verify external file contents or revision history. Check the linked file and record the exact version you reviewed.
What if two versions are marked Current?
Review the document group and resolve the conflict. The checkbox does not enforce one current record automatically.
Should I delete superseded drafts?
Keep them when they provide useful history, subject to your own retention process. Exclude them from the operational view rather than deleting them just to simplify it.
Explore the wider workflow
This register can sit alongside your existing projects. For a broader client and project workspace, explore Freelancer CRM and assess whether its structure fits your process.