Product pages stall when supplier facts, brand guidelines and approvals live in separate places. This workflow turns verified product information into reviewable copy, then updates only the approved fields without letting an AI model invent specifications or control publication.
In short
Use this workflow to draft product descriptions, benefit bullets and search snippets from an approved product record. A catalog editor checks factual claims and signs off on a specific revision before automation writes anything back to the store. It suits repeatable catalog work, not products whose safety or regulatory claims need specialist authorship.
The problem this workflow solves
The hard part of product content is usually not producing sentences. It is knowing which material composition is current, whether a capacity refers to one unit or a pack, and who approved the wording. Copying supplier text into a chatbot can conceal those distinctions behind confident prose.
Separate source facts from marketing language. For example, a verified record might say “500 millilitres, stainless steel, hand wash only.” The draft can explain the capacity, but it cannot add insulation performance, dishwasher compatibility or a health benefit. Missing facts should create questions for the buyer, not plausible additions to the page.
The operating unit is a product revision, not an entire store. Each run records the product identifier, locale, source revision, generated draft and approval status. That makes rejected drafts and later corrections traceable.
Who it is for
This is for merchants, catalog teams and agencies repeatedly preparing similar products with reliable specifications. A store owner can start with one category and one language, while an editor remains responsible for accuracy and tone.
Do not bother if you have a handful of products that rarely change, or if your source catalog is mostly contradictory supplier PDFs. Fix ownership and specifications first. For supplements, medical equipment, children's safety products or regulated claims, involve a qualified reviewer before treating the process as routine content production.
Tools and prerequisites
| Role | Example tools | Notes |
|---|---|---|
| Product source and destination | Shopify | Keep stable product IDs and a separate approved specification record. |
| Orchestration | n8n or Make | n8n provides product operations; Make can call documented APIs through HTTP. |
| Drafting | OpenAI API | Use a supported Structured Outputs model and an explicit response schema. |
| Review notification | Slack or your existing editorial queue | A message alerts the editor; the approval record controls the write. |
| Run ledger | Existing database or controlled catalog queue | Store revisions, approvals, errors and the previous field values. |
n8n documents Shopify get and update operations, while Make's HTTP app provides an alternative API transport. These are alternative implementations, not identical connector screens. Verify available fields, authentication scopes and current plan limits before choosing.
Prerequisites include store access limited to the necessary product scopes, a model API account, an approved tone guide and someone authorized to approve content. Keep credentials in the orchestrator's credential store. Give the drafting step no store credentials: it returns text, not executable actions.
Inputs and outputs
| Inputs | Outputs |
|---|---|
| Product ID, locale and approved source revision | Revision-linked content candidate |
| Verified dimensions, materials, compatibility and care facts | Description and benefit bullets grounded in those facts |
| Brand rules, prohibited claims and field length rules | Structured fields plus missing-information flags |
| Existing store text and source links | Before-and-after comparison for the editor |
| Named approval or rejection | Controlled store update or a correction request |
Define the output contract before prompting. Useful fields are product_id, locale, source_revision, description, benefit_bullets, seo_title, seo_description, claims_used and missing_facts. Keep the human approval outside this model-generated object so a generated “approved” value cannot authorize publication.
Workflow steps
Accept an eligible product revision. Trigger the run when an editor places a product in your controlled ready queue. Alternatively, use a Shopify product-change webhook followed by a readiness filter. Shopify documents product-update payloads and delivery metadata in its webhook delivery guide. Check the shop identity, authenticate incoming HTTPS deliveries and reject products outside the pilot category. Do not treat every inventory or app-driven update as a request for new copy.
Fetch and freeze the source. Get the current product record using the product ID, then attach the approved specifications and brand rules. Save a snapshot or immutable revision reference in the run ledger. Check units, pack sizes, variant differences and locale. If two sources disagree about the same fact, stop the draft and assign the conflict to the catalog owner. Never silently prefer whichever value appears first.
Deduplicate and establish the field boundary. Create a unique run key from shop, product ID, locale and source revision. If a completed or active run already has that key, do not generate another candidate. Record which fields this run may change. Exclude prices, inventory, tax settings, URLs, images and variants. An approved description revision should never become a general product rewrite.
Generate structured draft content. Call the model with only the verified facts, style rules and output contract. Require unsupported benefits to appear as questions under
missing_facts, rather than assertions. OpenAI Structured Outputs supports schema-constrained responses, but schema compliance does not establish factual accuracy. Check for refusals, incomplete responses and an unexpected product ID before continuing. Treat supplier text as untrusted input, not instructions.Run deterministic editorial checks. Parse the response and check required fields, allowed lengths, prohibited terms and literal specification values. Compare numerical claims against the source, including units and quantities. Flag statements such as “certified,” “waterproof” or “compatible with” unless an approved source explicitly supports them. Sanitize any generated HTML against a narrow allowed list, or convert reviewed plain text to safe markup yourself. A failed check sends the draft to correction, never to the store.
Collect revision-specific approval. Save the draft and a before-and-after comparison, then notify the editor. n8n's Slack node supports sending messages and waiting for a response. Configure an authenticated approver and persist their decision against the exact draft revision. Check that approval covers the product, language and fields shown; editing the draft after approval must invalidate that approval.
Write only approved fields. Re-fetch the destination and compare the fields being replaced with the saved baseline. If another editor changed them, pause for reconciliation. Use supported connector fields or Shopify's productUpdate mutation, which documents product updates and SEO settings and requires
write_products. Check GraphQLuserErrors, not just the HTTP status. This mutation does not update variants, and this workflow must not change product status or channel availability.Read back and close the run. Fetch the product again and compare the saved fields with the approved candidate. Record the resulting values, timestamp and editor. Preview the storefront rendering, especially lists, special characters and mobile truncation. Mark the revision complete only after verification. If the write outcome is uncertain, read before retrying; if it is wrong, restore the previous approved text after checking for subsequent human edits.
Human-review checkpoints
The catalog owner approves the source facts before drafting. This is where ambiguous sizing, missing certification evidence and contradictory supplier statements must be resolved. A model is not the tie-breaker between two documents.
The content editor approves the actual destination fields before writing. Review claims against evidence, not just grammar, and inspect whether benefits imply guarantees the specifications never made. A search snippet is still customer-facing content and needs the same factual standard as the main description.
The first batch also needs a storefront check by someone familiar with the theme. Confirm that the product remains in its intended publication state and that no unrelated app overwrote the changes. Keep manual release control until repeated batches show that the field mapping and review process are dependable.
Limitations, privacy and failure cases
Exposure and retention: exclude customer orders, personal data and supplier banking details. Unreleased products and confidential manufacturing information may still be sensitive. Review provider processing terms, geographic requirements and deletion procedures. OpenAI's data controls distinguish abuse-monitoring logs from application state; do not assume every endpoint has the same retention behavior. Limit raw execution-log access and retention too.
Hallucinations and content rights: fluent text may introduce unsupported comparisons or reuse supplier phrasing too closely. Require evidence for every material claim and confirm you can use the supplied source material. Do not invent testimonials, review counts, sustainability labels or certification marks.
Duplicate events and loops: your own update can cause another product-update event. Use the source-revision key and readiness rules to prevent circular drafting. A completed revision stays completed unless an authorized user explicitly requests a new version.
Rate limits and partial failures: process a bounded queue, retry transient errors with backoff and cap attempts. Put persistent failures in an exception queue with the product ID and safe diagnostic details. Never repeat the whole workflow automatically after a timeout if the product write may already have succeeded.
Concurrency: a pre-write comparison reduces accidental overwrites but is not an atomic lock. During a pilot, serialize writes per product and use an editorial freeze for the brief update window. If multiple apps edit descriptions, establish one owning system before scaling.
Setup effort
Estimate an afternoon to a day for a small draft-only version, assuming clean product records, existing credentials and one language. Allow several days for authenticated approvals, safe HTML handling, conflict detection, retries and read-back verification. These are planning estimates, not measured deployment times. Multilingual catalogs and category-specific compliance rules add work; check current plan limits for automation runs and model usage before expanding.
Questions About E-commerce Product Content
Can this publish products automatically?
The blueprint updates approved text only. Product status and channel publication remain outside its permissions and field mapping wherever practical. Publishing a new product should be a separate authorized decision.
Can one description cover every variant?
Only when the claims are true for every variant it describes. If materials, capacities or compatibility differ, supply variant-specific facts and make the distinction explicit. Do not infer variants from a parent title.
How should translations work?
Treat each locale as its own reviewed revision with approved terminology and locale-specific claims. This blueprint does not implement Shopify translation writes; add that only after separately verifying the translation API and local review requirements.
Related on AIMBIGTECH
- Shopify Review: Is It Still the Default for Online Stores?
- A Practical Guide to Effective AI Prompting
- How to Start Using AI Automation: A Practical Checklist
- Shopify directory profile
- n8n directory profile
Sources
- Shopify — productUpdate
- Shopify — Webhooks delivery structure
- n8n — Shopify node
- n8n — Slack node
- OpenAI — Structured model outputs
- OpenAI — Data controls in the OpenAI platform
- Make — HTTP