A vendor product data portal in Airtable can collect proposed descriptions, product codes and images without letting suppliers overwrite your approved catalog. Use miniExtensions to give each vendor a focused submission checklist, then let an editor review and deliberately apply accepted changes to the catalog.

Imagine fictional Harbor Supply preparing its seasonal range. A vendor sends updated descriptions and photographs for three storage products. One image is suitable, one description uses an unsupported claim and one product code conflicts with an existing item. The team needs to review each proposal independently rather than copying an entire spreadsheet straight into the public listing source.

Keep proposed content separate from approved content

Build the following example structure in a connected Airtable base:

  • Vendor contacts: Name as primary single-line text, Email as an email field and Vendor name as text.
  • Catalog: Internal product reference as text, Vendor name as text, Approved vendor SKU as text, Approved title as text, Approved description as long text, Approved images as an attachment, Publication state as a single select and Last reviewed on as a date.
  • Product submissions: Submission reference as text; Vendor contact and Catalog item as linked records; Proposed SKU and Proposed title as text; Proposed description as long text; Proposed images as an attachment; Source revision as text; and Vendor notes as long text.
  • Product submissions, editorial fields: Review state as a single select, Editorial feedback as long text, Reviewer as text, Reviewed on as a date, Applied on as a date and Supersedes submission as a linked record to Product submissions.
  • Approved changes: Change reference as text, Submission and Catalog item as linked records, Fields applied as long text, Prior values as long text, Applied by as text and Applied on as a date.

Each Product submissions record proposes one product revision. Staff links Catalog item after identifying the intended item. A new product can remain unlinked until the editor creates its catalog record. Do not use the proposed SKU alone as proof of identity, especially when different suppliers may use the same code.

The Catalog holds the approved working copy. Approved changes records provide ordinary operational context about an application step, not an immutable audit trail. If formal retention is required, assess that separately rather than assuming a text field provides it.

Give vendors their own submission checklist

Create a miniExtensions Portal with Product submissions as its Data Table and Vendor contact as its User Field. Follow the Users table documentation for the direct relationship. Keep Catalog and Approved changes outside the vendor portal in this first version.

Configure email verification under Users & Login using the verification instructions. For each private view, go to Portal Tables, select Product submissions, open Views and the view, then Filter and Sort. Set Choose Records to Display to Personal records only (linked to the logged in user). The record visibility guide explains the setting.

Staff creates a requested submission for each expected product and links it to the correct Vendor contact. Vendors edit only their proposed content and notes. Keep Catalog item, Review state, Reviewer, Reviewed on and Applied on out of their editable inputs; show Editorial feedback as read-only.

This deliberately starts as a prepared checklist. If vendors later need to propose entirely new products, configure that creation route separately and verify its user links. Do not expose a selector containing other vendors’ catalog entries merely to make intake easier.

Write instructions that make the content reviewable

Ask for the intended public product name, a description suitable for your audience, the supplier’s exact SKU and the current approved image files. Use Source revision for a meaningful version or issue date supplied by the vendor. Give examples of the information your catalog needs, such as dimensions and material, without treating those examples as automatic validation.

Ask vendors to explain changes from the previous version in Vendor notes. “Corrected the width from 40 to 45 cm” tells the editor what to inspect. Avoid requesting unrelated customer information, internal price agreements or credentials in the description or attachments.

Use Maximum allowed files on Proposed images to keep submissions manageable; the attachment-count guide explains that existing files count. File acceptance does not confirm image quality, factual accuracy or usage permission. Your editor still checks the content and the organization’s rights process.

Review each revision before applying it

Suggested Review state choices are Requested, Ready for review, Correction needed, Accepted and Applied. Staff maintains the decision states. For Harbor’s three submissions, the editor accepts the clear image set, returns the unsupported wording with specific feedback and investigates the conflicting SKU before linking it to any existing catalog item.

Check the intended reader outcome: can someone identify the product, understand its relevant specifications and distinguish it from similar items? Compare proposed values with the current approved record. An accepted description does not imply that every attached image has been accepted, so Editorial feedback should name any exclusions.

When the review is complete, the editor applies only the approved fields to Catalog and creates an Approved changes record identifying what changed. Copy selected approved images deliberately; do not assume that attaching files to a submission synchronizes them with the catalog. Record Applied on only after inspecting the actual catalog values.

Preserve accepted revisions when corrections arrive

Keep accepted and applied submissions out of the editable vendor queue. In their history view, use the view editing restriction to disable expansion and editing. Inspect other views and related creation or unlinking routes too; one restricted view does not make the record globally read-only.

For a later correction, create a new submission linked through Supersedes submission. Preserve the earlier proposed text, editorial decision and application record. If the vendor discovers that a published measurement is wrong, the editor must assess the affected live listing and correct it through the separate publication process; merely accepting a new submission does not update the website.

The product catalog guide covers the browsing experience. This workflow sits before it, preparing reviewed catalog data. Public publication, exports and storefront synchronization are separate operations that require their own checks.

Check the staging boundary before launch

Use two fictional vendors to test record visibility and editing. Submit one changed description, one new product and one conflicting SKU. Confirm that nothing in Catalog changes until an editor applies approved fields. Then close a revision and verify that a vendor must use a new submission for the next correction.

These are recommended tests, not observed results. This design fits a team that can review proposals and publish deliberately. Its main benefit is a clear boundary between vendor-supplied information and the content your organization has decided to use.