A correction arrives by email just as another proof is ready to leave the studio. The comment says “use the previous cover”, but the job folder contains three previous covers. Before anybody changes the artwork, the team needs to establish which file the reviewer saw. A small proof log can make that conversation much shorter.
For a studio already using Notion, start with one database containing a separate record for each issued proof. Keep the actual artwork and the agreed approval process in their established systems. The Notion record gives the coordinator somewhere to connect the file, the feedback and the next action.
Give each issued proof its own identity
Name a record with the job code, component and revision: for example, “BK-104 cover R03”. Agree the revision convention before using it. A filename such as “cover-final-new.pdf” leaves too much to interpretation, especially when the text pages and cover are revised separately.
Add fields for the exact proof filename, a link to that file, the issue date, the person coordinating the response and the decision. Text, URL, Date, Person and Select are available in Notion’s documented database properties. Use a Person field for a coordinator who belongs to the workspace; use Text if the field simply records a contact’s name. Suggested decision choices are Issued, Changes requested, Approved and Superseded.
Keep the proof link tied to that revision. If a link opens a file that is silently replaced with R04, the R03 record no longer identifies what was reviewed. Use your file system’s version-specific reference where available, and check the destination whenever a proof is issued.
Separate the job from its review rounds
One job can have several proof records, each with its own response. Put the overall delivery date and brief on the job page. For teams handling repeat clients, the guide to linking clients, projects and tasks in Notion explains a structure that can sit around this proof log. Start with the smallest arrangement the coordinator can maintain.
Inside each proof record, record feedback with its location and requested change: “R03, back cover, second paragraph: change the author’s name to the supplied spelling.” Link to the original feedback in the authorised internal location. Preserve the wording of an approval rather than replacing it with someone’s summary of “looks fine”.
When R04 is issued, make a new record and retain R03 with its comments. Note which revision R04 replaces. A request to change R03 is still a request to check against the revised file; it does not establish that R04 has been approved.
Review the handoff before production
Create a working view for decisions awaiting a response and keep an unfiltered table alongside it. Filters help organise the queue. A record missing from a filtered view still needs checking in the full table, particularly when somebody has left its decision field blank.
Before releasing the job, open the identified file and compare its filename and revision with the recorded decision. Confirm who approved it, what was approved and whether any conditions remain. Check covers, text sections and other components separately when their approvals differ. Record the release decision through the team’s established production controls.
Try the log with a fictional job before entering live work: issue R01, record a correction, then issue R02. Ask a colleague to find the current proof and explain what still needs a response. If maintaining the surrounding workspace becomes the obstacle, NotionSolutions has further guides to database views and project organisation. Keep only the fields that help the next person identify the right file and act on the right feedback.
