A creative proof review queue in Airtable can connect each deliverable, each submitted version and each reviewer’s decision. With a miniExtensions portal, reviewers can open their assigned review records, mark up an image and submit feedback against the version they actually reviewed. The useful outcome is a clear answer to “Which version did this person approve?” rather than another folder of loosely related comments.

This example is for a small design studio reviewing campaign images with a client. The fictional project is Cedar Studio’s spring campaign. Its website banner has two reviewers, a marketing lead and a copy reviewer. The workflow below is a proposed setup using documented capabilities, not a report of a tested deployment.

Keep the proof and its review decisions separate

Use four tables so a new file does not silently replace the context for an old decision:

  • Deliverables: Name as single-line text, Project as single-line text, and Coordinator as a collaborator field. “Spring website banner” is one deliverable.
  • Versions: Version name as single-line text, Deliverable as a linked record, Original proof as an attachment, Shared on as a date, and Version state as a single select. Suggested states are Preparing, In review and Superseded.
  • Reviewers: Name as single-line text and Email as an email field. Use one record per reviewer.
  • Feedback: Version and Reviewer as linked-record fields, Review image as an attachment, Decision as a single select, Comments as long text, and Review status as a single select. A lookup of Version name makes the context visible.

Create one Feedback record for each reviewer and version. For example, “Banner v2 / marketing review” and “Banner v2 / copy review” both link to Banner v2, but their decisions remain independent. The coordinator copies the relevant proof into each Review image field. That copying is a manual preparation step in this design; no automatic file synchronization is assumed.

Give reviewers a focused working record

Set up the portal using Feedback as the data table and Reviewer as its direct link to the Users table. The Users table guide explains the relationship. If you add other portal tables later, review their user links separately.

For every reviewer-facing view, use Choose Records to Display → Personal records only (linked to the logged in user) under the view’s Filter and Sort settings. Follow the personal-record filtering instructions. Test with two fictional reviewer accounts before inviting anyone. A record label or hidden field is not a substitute for checking what each account can actually access.

Show the version label, review image, Decision and Comments. Keep the coordinator’s original proof and internal production fields outside the editable review form. Use a suitable login configuration; the email-verification guide covers the documented verification option.

Use image annotation for a concrete correction

miniExtensions documents Image Annotation as an attachment-field mode. In the Review image field settings, open Upload Settings and choose Field Mode → Image Annotation. The reviewer selects an image, chooses Annotate, adds marks or comments, and saves with the annotation editor’s checkmark. See the image annotation instructions.

For the banner example, the marketing lead circles the headline and writes “Increase contrast here.” They choose Changes requested and explain the desired change in Comments. The copy reviewer can approve the wording while the marketing review remains unresolved. Opening the image or saving an annotation does not establish approval; the explicit Decision field records that choice.

Use Pending, Changes requested and Approved as your own Decision choices. These labels are workflow design, not a built-in approval engine. Check the submitted fields before treating the review as complete. If the annotation or written decision is missing, the coordinator follows up rather than inferring intent.

Handle a new version without losing the earlier conversation

When the designer produces v3, create a new Versions record and new Feedback records. Keep v2 and its reviews intact. Mark v2 Superseded after confirming which version is now being reviewed. Do not relabel the old Feedback record as v3, because that would attach yesterday’s approval to a different image.

If one reviewer responds late to v2, the coordinator checks whether the comment still applies and asks for a v3 decision when needed. A late approval should not advance the current deliverable automatically. Similarly, a corrected typo after approval creates a policy question for the studio: decide whether it requires another review and record that decision explicitly.

The coordinator reviews all required current-version decisions in Airtable before handing the final asset to production. A custom “Ready for production” field can record that handoff, but it should be updated only after the actual review. This article does not assume that a formula or automation can judge whether every creative objection has been addressed.

Check the workflow before using it with a client

  • Confirm each fictional reviewer sees only the intended Feedback records in every enabled view.
  • Annotate a sample copy, reload it, and verify the saved mark without changing the protected original proof.
  • Approve v2, then create v3 and verify that v3 starts without an inherited approval.
  • Submit conflicting decisions and verify that the coordinator’s queue still makes the unresolved review visible.
  • Confirm how closed reviews are protected from unintended later edits in your chosen configuration.

This setup suits lightweight image review with a human coordinator. It does not promise immutable version history, legally binding sign-off, advanced PDF proofing or layered design-file editing. For a broader two-party request workflow, see the two-role approval portal guide. Here, the distinguishing requirement is that every creative decision stays attached to one explicit proof version.