Imports are run ad hoc whenever a source sends new data, so the same checks are redone by hand and partial failures pass unnoticed. In this case, the immediate task is to prepare a repeatable product import workflow. The workflow should produce a validated import draft with a row-level exception list, tested against the merchant's records.
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.
Act as a Shopify operations specialist.
Help me prepare a repeatable product import workflow.
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: [each import source with its location, field list, update cadence and owner, the column-to-schema mapping, the key identifying an existing product, the stated overwrite permissions, and the expected handling of new, changed and withdrawn rows]. Fix the run order — validate structure and required fields first, resolve every row against the catalog key, then write changes only where the stated permissions allow overwriting — writing down what each step does on failure, and flagging rows whose key does not resolve, whose required fields fail validation, or whose incoming value would replace a corrected store value the mapping never authorized.
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.Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
Collect each import source with its location, field list, update cadence and owner, the mapping carrying its columns onto the product schema, the key used to recognize an existing product, and what should happen to rows that are new, changed or no longer supplied.
Fix the run order — validate structure and required fields first, resolve every row against the catalog key, then write changes only where the stated permissions allow overwriting — writing down what each step does on failure, and flagging rows whose key does not resolve, whose required fields fail validation, or whose incoming value would replace a corrected store value the mapping never authorized.
Deliver the sequence as a reusable checklist with a validated import draft, a row-level exception list giving row number, source, field, message and proposed correction, and a run record counting rows read, created, updated and rejected, then reconcile those counts against the source so nothing is silently absorbed.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
The same mapping, the same validation order and a written record of the outcome every time. Ad hoc corrections during a run are what break repeatability, because the next operator cannot know which rule actually ran; any change to the sequence is approved first and then recorded as a new version of the checklist.
By counting rows at each stage — read, resolved, written, rejected — and reconciling all four against the source before closing the run. A run that halts midway keeps its completed rows recorded and reports what failed to land, so nothing is retried blindly and no failed row is mistaken for a finished one.
Reuse it, then revalidate it against the current file before every run, because supplier columns shift without notice. Any header that no longer matches is listed for review rather than matched by position, since a silent remap writes today's values into yesterday's fields and surfaces much later as corrupted data.
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
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.