PlaysbyMoat8
Back to the library
The workflow guideOperations

Build a product catalog from a CSV

Import product records from a spreadsheet into a commerce catalog, previewing changes and checking product matches before applying them.

6 implementation stepsIntermediate

How this works

Import product records from a spreadsheet into a commerce catalog, previewing changes and checking product matches before applying them.

Import catalog rows as explicit creates or updates using stable product and variant identifiers. Preview all price and inventory-related differences before writing; preserve original row numbers for reconciliation and rollback.

Before you start

Defined operating scope

Product records arrive in spreadsheets and must be matched to existing commerce records.

Required source material

Obtain Product CSV; Prices and currencies; Category and variant rules. If connectors are unavailable, use authorized files with the same fields.

Decision and exception rules

Two rows share a variant key. Hold both and resolve the duplicate rather than accepting the last row silently.

Prepare the inputs

product_csv
Required

Rows with stable product and variant IDs

Reject duplicate keys within the import.

field_mapping
Required

CSV-to-catalog map

Specify required fields and blank-value behavior.

price_rules
Required

Currency, tax basis and decimal precision

Amounts require valid numeric parsing.

target_store
Required

Store and environment ID

Confirm sandbox versus live destination.

Implementation, step by step

  1. Establish the working record

    • Confirm the selected records, effective versions and responsible owner.
    • Check product_csv, field_mapping, price_rules, target_store before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.

    Checkpoint: The input record identifies the selected product_csv and any missing required fields.

  2. Map spreadsheet columns to catalog fields

    • Map columns and parse identifiers as strings so leading zeros survive; distinguish blank cells from deliberate clearing.
    • Reconcile create, update, skip and error counts to every input row.

    Checkpoint: A saved intermediate result for: Map spreadsheet columns to catalog fields.

  3. Review proposed record creations and updates

    • Join rows to existing records using stable keys and prepare a change preview, including variants and category assignments.
    • Check currency, decimal parsing, variant identity and before/after prices in the saved catalog.

    Checkpoint: A saved intermediate result for: Review proposed record creations and updates.

  4. Apply a small batch that can be checked

    • Apply a small authorized batch with recorded before-values; verify each response and stop on inconsistent matches.
    • Reconcile create, update, skip and error counts to every input row.

    Checkpoint: A saved intermediate result for: Apply a small batch that can be checked.

  5. Reconcile the catalog and prepare the required payment links

    • Reconcile source rows to saved products and variants, then prepare payment links only for the confirmed target records if requested.
    • Check currency, decimal parsing, variant identity and before/after prices in the saved catalog.

    Checkpoint: A saved intermediate result for: Reconcile the catalog and prepare the required payment links.

  6. Package the result and unresolved work

    • Check prices, taxes, variants, duplicates, and the selected store and environment.
    • Preview locally without approval; live catalog mutation requires the user’s authorized import scope.

    Checkpoint: A catalog linked to its original spreadsheet rows. Unresolved items remain visible in the review record.

Decisions along the way

Two rows share a variant key.

Hold both and resolve the duplicate rather than accepting the last row silently.

A blank price appears in an update.

Apply the declared blank-value rule; never interpret missing price as zero.

An import response is incomplete.

Read the target records and reconcile succeeded rows before retrying.

What you will produce

csv-to-store-catalog-result.json

JSON

A catalog linked to its original spreadsheet rows. Label proposed and completed states separately.

Include: source_row · product_id · variant_id · operation · before_values · proposed_values · saved_record_id · status · evidence_reference · review_note

csv-to-store-catalog-review.md

Markdown

Keep the evidence and unresolved decisions needed to apply this result, including exceptions involving target_store.

Include: source_reference · question · owner · next_action

Check the result

  • Reconcile create, update, skip and error counts to every input row.
  • Check currency, decimal parsing, variant identity and before/after prices in the saved catalog.
  • Inspect product_csv and field_mapping in both the original and output; confirm that record identity and interpretation survived the transformation.
  • Check prices, taxes, variants, duplicates, and the selected store and environment.

When something goes wrong

Two rows share a variant key.

Hold both and resolve the duplicate rather than accepting the last row silently. Retain the affected evidence and recovery status.

A blank price appears in an update.

Apply the declared blank-value rule; never interpret missing price as zero. Retain the affected evidence and recovery status.

An import response is incomplete.

Read the target records and reconcile succeeded rows before retrying. Retain the affected evidence and recovery status.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Build a product catalog from a CSV for the following bounded example; prepare the result for review.

Inputs

Synthetic example: CSV row 2 has variant 0012 at 19.50 EUR; row 3 repeats 0012 at 21.00 EUR. Target store is a sandbox.

Expected result

Synthetic expected result: Both rows are held as conflicting duplicates; variant ID retains its leading zeros. No update is applied until the intended price is confirmed.

Run a small pilot

Start small

Trial a representative batch containing the ordinary case and the exception demonstrated above.

Record the baseline

Record current preparation time, review effort and correction types for the same records.

Agree success criteria

Agree acceptable review and error limits; measure time per verified import batch; incorrect product, variant, price, or currency updates.

Stop or revise

An import response is incomplete. Pause affected records and apply this recovery: Read the target records and reconcile succeeded rows before retrying.

Keep the scope clear

  • Preview locally without approval; live catalog mutation requires the user’s authorized import scope.
  • Do not alter stock, payment settings or unrelated products merely because the CSV contains extra columns.

Check before using

Check prices, taxes, variants, duplicates, and the selected store and environment.

Business activities

  • Manage product catalogs and storefronts

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Product CSV · Prices and currencies · Category and variant rules

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗