Back to topic
Spark playbook scenarios · Spark: AI Store Assistant

Prepare a validated batch of product listings for upload

The batch is ready to upload, but the store returns errors on some rows and it is unclear which the merchant must answer. In this case, the immediate task is to prepare a validated batch of product listings for upload. The workflow should produce a validated import draft with a row-level exception list, with counts confirmed against the merchant's records.

Topic
Product Creation and Import
Target keyword
shopify bulk product upload
Copyable AI prompt

A prompt you can drop directly into Spark

First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.

ai-prompt.txt
Act as a Shopify operations specialist.
Help me prepare a validated batch of product listings for upload.
My store context is [describe the business, products and target audience].

My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [the listing batch, the required upload fields, per-field validation rules, error messages from previous attempts, and the merchant decisions still outstanding on open rows].

Validate every row before uploading, correcting only what the rules settle on their own such as a disallowed character or a missing column, separating rows that need a merchant decision, and flagging rows whose identifier already exists, whose option names repeat inside one product, or whose required relationships to existing handles are absent.
Return a validated import draft with a row-level exception list for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.
Use in Spark
How to solve

A recommended resolution workflow

Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.

01

Step 1

Collect the listing batch, the required upload fields, the validation rule applying to each field, any error messages returned by a previous attempt, and the answers only the merchant can supply for fields still open.

02

Step 2

Validate every row before uploading, correcting only what the rules settle on their own such as a disallowed character or a missing column, separating rows that need a merchant decision, and flagging rows whose identifier already exists, whose option names repeat inside one product, or whose required relationships to existing handles are absent.

03

Step 3

Deliver the batch split into an upload-ready draft and a row-level exception list naming the row, the field, the returned message and the input that would clear it, then reconcile uploaded, exception and open rows against the original batch count and upload in batches small enough that any failure traces back to its own rows.

FAQ

Common questions when running this scenario

Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.

Why split the batch before uploading?

Rows the rules can settle should move, while rows awaiting a merchant decision should neither hold them back nor be guessed into validity. Uploading everything at once collapses two different problems into one failure report, whereas splitting lets the clean set go live while open questions are answered.

How large should one upload batch be?

Small enough that a returned error can be traced to the rows causing it. Oversized batches make failures expensive to localize and risk repeating rows that partly succeeded, so the practical test is whether a single abort leaves an ambiguous set of writes behind.

What should be resent after a failed run?

Only the corrected rows from the exception list. Resending the full file repeats every failure and duplicates whatever already landed, so the run record showing which rows were written is checked first, and the re-run is reconciled against that record rather than the original file.

Related scenarios

Continue with adjacent or same-topic scenarios

Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.

Next step

Want these AI scenarios embedded directly into daily operations?

Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.