A Sanity Studio Workflow for Reviewing Image-Edit Requests Before Production

Most teams don't lose time on the actual image edit. They lose it on the back-and-forth before anyone agrees what the edit should be. A designer swaps a background, someone asks for a different crop, an accessibility reviewer flags missing alt text after the fact, and the final asset ships without anyone quite remembering who approved what. If your team manages visual content inside Sanity Studio, the fix isn't a new tool—it's a small, deliberate content model that forces the request to be explicit before any pixel changes.

Why image-edit requests deserve their own document type

Treating an edit request as a comment on an existing image document usually fails, because comments don't have required fields, validation, or a lifecycle. A dedicated imageEditRequest document type gives you a place to capture intent, constraints, and approval as structured data instead of a Slack thread that evaporates in two weeks. It also gives editors a queryable record: which requests are pending, which are approved, and which assets are cleared for downstream production work like a poster layout or a product shot.

The goal isn't bureaucracy for its own sake. It's making the handoff between the person requesting a change and the person (or tool) executing it unambiguous.

Designing the schema

A workable schema needs six things: a reference to the source asset, a plain-language statement of edit intent, explicit constraints, accessibility notes, an approval status, and a place to record the downstream handoff. Here's a simplified example:

export default {
name: 'imageEditRequest',
title: 'Image Edit Request',
type: 'document',
fields: [
{name: 'sourceAsset', title: 'Source Asset', type: 'image', validation: Rule => Rule.required()},
{name: 'editIntent', title: 'Edit Intent', type: 'text', validation: Rule => Rule.required().min(20)},
{name: 'constraints', title: 'Constraints', type: 'array', of: [{type: 'string'}]},
{name: 'accessibilityNotes', title: 'Accessibility Notes', type: 'text'},
{name: 'approvalStatus', title: 'Approval Status', type: 'string',
options: {list: ['draft', 'in review', 'approved', 'rejected']}, initialValue: 'draft'},
{name: 'handoffChecklist', title: 'Handoff Checklist', type: 'array', of: [{type: 'string'}]}
]
}

The validation on editIntent matters more than it looks. A one-word intent like "brighter" gives whoever executes the edit nothing to work from. Requiring a minimum length nudges requesters to actually describe the change.

A hypothetical worked example

Imagine a small marketing team preparing a seasonal poster. A requester creates an imageEditRequest document referencing the current hero photo. The edit intent reads: "Replace the studio background with a warm outdoor scene, keep the subject's pose and lighting direction unchanged, and preserve the existing crop ratio for the print template." Constraints list two items: "no visible text overlay changes" and "maintain skin-tone accuracy." The accessibility notes field records that the final image will need updated alt text once the background changes, since the current description mentions the studio setting explicitly.

This is a hypothetical scenario, not a documented case, but it illustrates the pattern: intent, constraints, and accessibility needs are captured before anyone opens an editing tool. A reviewer can read this single document and understand exactly what "approved" will mean, rather than approving a vague idea.

Approval and handoff checklist

Once the request document exists, approval should follow a repeatable check rather than a gut call. A simple reusable checklist works well as either a Studio field array or a printed reference for reviewers:

• Source asset is correctly referenced and at production resolution
• Edit intent describes the change in specific, non-technical language
• Constraints list anything that must not change (crop, text, brand colors, pose)
• Accessibility notes are updated to reflect the post-edit content
• Approval status reflects an actual decision, not a default value
• Handoff checklist names the next tool or person and the expected return format

Only when every item is checked should approvalStatus move to "approved." This keeps the record honest instead of aspirational.

Where an external image tool fits, after approval

Once a request is approved, the actual editing can happen wherever your team already works. Some teams sketch options in a general design tool; others use an AI-assisted workspace to generate or refine variations from the approved reference and intent. If your workflow includes an AI-driven step, a tool like Muse Image can serve as that downstream workspace for turning the approved reference and prompt-style intent into finished visuals, which then get uploaded back into Sanity as the final asset. This is a separate step from the review process described here, not a built-in integration—the two systems don't need to talk to each other automatically for this workflow to hold up.

Limitations and where this breaks down

This model assumes people fill in the fields honestly and completely, which won't always happen under deadline pressure. A required field can be satisfied with a lazy one-line answer that technically passes validation but tells the next person nothing useful. Sanity's schema validation can enforce presence and length, but it can't judge whether an edit intent is actually clear.

The correction is procedural, not technical: reviewers should reject requests that pass validation but fail the spirit of the checklist, and the approvalStatus field should never move to "approved" just because every field is non-empty. Treat the checklist as a conversation starter for reviewers, not a substitute for their judgment. Teams that skip this distinction end up with a tidy-looking dataset full of approved requests that never should have passed review.

Used this way, a structured image-edit request model won't stop every miscommunication, but it does make the request itself the source of truth—something a Slack thread never manages to be.

Sanity – The Content Operating System that ends your CMS nightmares

Sanity replaces rigid content systems with a developer-first operating system. Define schemas in TypeScript, customize the editor with React, and deliver content anywhere with GROQ. Your team ships in minutes while you focus on building features, not maintaining infrastructure.

Sanity scales from weekend projects to enterprise needs and is used by companies like Puma, AT&T, Burger King, Tata, and Figma.