An Airtable product-photo workflow can keep original images, smaller website copies, and the human publishing decision together. Use a separate asset record for each photograph, process copies with miniExtensions, and let a reviewer choose which version is ready for the website. A successful image-processing run should not automatically mean that a photo is approved or already live.

This fits a small catalog team preparing a new collection, replacing supplier images, or standardizing a backlog of product photography. The useful outcome is a reviewed set of images tied to the right products, with the originals still available when the next channel needs a different size.

Follow one product from original photo to approved web image

Imagine Cedar Goods preparing a ceramic mug and a linen pouch for its website. Each product has a front photograph and a detail photograph. The mug’s original files are large; one pouch photograph is sideways. The merchandising coordinator wants a consistent image width, but the website editor must still check the product, composition, and visible details before using anything.

Give the photographer responsibility for source files, the coordinator responsibility for processing, and the website editor responsibility for acceptance and upload. These may be the same person in a small team, but the decisions remain separate. Use ordinary sample photos you have permission to process while setting up the workflow.

You need an Airtable base, a connected miniExtensions workspace, and a plan suitable for the intended automation workload. Check the current plan limits before running a large collection. The Free plan is for internal testing and processes one record at a time, with a daily processing limit; do not assume the example is an unrestricted production allowance.

Keep product identity separate from image versions

Use a Products table for the catalog and a Photo Assets table for the individual files. One original photo per asset record makes it easier to identify an unsuitable output without rejecting every photo of the product.

  • Products: Product Name (primary single line text), SKU (single line text), and Website Page (URL).
  • Photo Assets: Asset Reference (primary single line text), Product (link to Products), Shot (single select: Front, Detail, Lifestyle), and Revision (number).
  • Image fields: Original Photo and Processed Photo, both attachment fields. Keep these as two different fields.
  • Review fields: Stage (single select: Received, Ready to Process, Review, Approved, Needs Replacement, Superseded), Reviewer (single line text), Review Date (date), and Review Notes (long text).
  • Handoff fields: Intended Use (single line text), Processing Notes (long text), and Website Upload Date (date).

These tables and statuses are a suggested operational design. Creating them does not install a built-in photo approval process. Staff maintains the stages and dates in this first version.

For example, MUG-FRONT-01 links to the ceramic mug, with Shot set to Front and Revision set to 1. MUG-DETAIL-01 holds its detail image. POUCH-FRONT-01 and POUCH-DETAIL-01 belong to the pouch. Put a replacement front photograph in MUG-FRONT-02 rather than silently replacing the original in MUG-FRONT-01. A separate record preserves the earlier review context; Airtable attachments alone are not a dedicated digital-asset versioning system.

Agree on an output requirement before processing

Ask the website editor which image dimensions the actual theme or storefront expects. For this example, the team chooses a 1,200-pixel-wide product image and allows the height to follow the original proportions. That is an example requirement, not a universal ecommerce recommendation. A different website might need a square crop or several responsive sizes.

Separate photos that need composition work from those ready for simple resizing. A portrait photo and a landscape photo can have the same width but different heights. If the layout requires an exact crop, use the team’s cropping process before accepting the output instead of assuming that resizing will choose the right composition.

Record the chosen settings in Processing Notes, such as “Website product image, width 1200, proportional height, reviewed for this collection.” Do not promise a fixed percentage reduction or a guaranteed file size. The source photograph and the selected operations affect the result.

Process a small, explicit selection

Create a Photo Assets view named Image Processing Sample. Include one representative asset whose Stage is Ready to Process and whose Original Photo is present. Open the view and check the actual row before running anything. Start with a second, separate sample when you need to check another source format or orientation.

Create the miniExtensions Compress and Resize Images automation against Photo Assets. Map Original Attachments Field to Original Photo and Processed Attachments Field to Processed Photo. Enable Resize Images and use Image Width for the example requirement, leaving Image Height and Image Scale unused. Setting only one dimension preserves proportions; use a scale or explicit dimensions, not both methods. The photo-editing guide explains these controls and the separate input/output requirement.

Enable compression only if it serves the website requirement, then compare the chosen quality on a sample. Keep rotation off for already upright photographs. Process the sideways pouch image in a separately checked selection with the appropriate rotation rather than applying that rotation to every product photo.

Use the automation’s Filtering option to select Image Processing Sample, following the record-filtering guide. The selected view controls the processing set; an unrelated portal’s filters do not define that set. Avoid changing the selected records while a run is being prepared.

Run the sample manually through the Run section. Check the run result and inspect the output field. Staff then moves the asset to Review. The automation creates image copies; this design does not assume it also advances Stage, notifies a reviewer, or uploads anything to the website.

Approve the actual image, not the successful run

The reviewer should open the processed file beside the original and check the product, color appearance, orientation, readable labels, and important details. Inspect the image at a useful viewing size, not only as a small Airtable thumbnail. Confirm the output dimensions and file size using the file’s properties or the team’s image tool.

Also preview the image in the intended website layout before replacing a live asset. An image may look acceptable by itself but crop awkwardly inside a product card. For a HEIC source, the documented workflow converts it to JPG before applying the selected operations, so do not assume the output preserves every aspect of the original format.

Once the file is accepted, staff records Approved, the reviewer, date, and any handoff note. Keep Review Notes clear enough to explain a rejection: “Front label becomes unreadable at the selected quality” is more useful than “Bad image.” A Needs Replacement record stays out of the release queue even if Processed Photo contains a file.

Handle a replacement without publishing stale output

Suppose the photographer supplies a sharper mug photograph after the first image was approved. Create MUG-FRONT-02 with the replacement original and an empty Processed Photo field. Keep the earlier approved row intact while the new one is processed and reviewed. Staff decides when to mark the old asset Superseded.

This matters because automation processing uses the output field’s current contents, rather than remembering an asset’s approval history. An existing output can cause a record to be skipped. Changing a source does not itself establish that the output now represents that new source.

If you deliberately reprocess an existing row, first preserve the accepted image through your normal file-retention process and remove it from the release queue. Review Existing Data Handling before choosing Overwrite. That setting can process eligible records again on each run. It is not a safe substitute for checking the selected view, and a reprocessed file needs a new review.

Make the website handoff a separate step

Create an internal release view requiring Stage to be Approved and Processed Photo to be populated. The website editor checks the asset reference, product SKU, intended slot, and review decision before downloading the exact accepted file and uploading it through the website’s normal media process.

Record Website Upload Date only after checking the website result. A manually entered date is coordination evidence, not an automatic deployment receipt. If the wrong product photo appears, inspect that product’s asset mapping and website selection before repeating the image-processing run.

For several accepted assets, the attachment handoff guide can help organize a reviewed download package. This article adds the earlier image-preparation and acceptance stages. It does not configure a storefront integration, automatic product-page update, or permanent image-hosting service.

Check the workflow before expanding it

  • Process a normal sample and confirm the original attachment remains unchanged.
  • Check a sideways image separately and verify that upright images are not accidentally rotated.
  • Compare a representative source format, output dimensions, and visible details.
  • Leave an unsuitable output in Needs Replacement and confirm it is absent from the release view.
  • Add a replacement as a new revision and verify that the previous accepted file and notes remain available.
  • Check the output-handling behavior on a harmless sample before any deliberate rerun.
  • Upload one accepted image through the real website process and check its actual product placement before handling a larger collection.

The resulting system gives the team a practical answer to three questions: which source did this image come from, who accepted the website copy, and has the editor actually used it? Image processing supports that workflow; the review and release decisions make the files dependable enough to hand over.