How to Turn Shopify Product Data Into a Queryable Support Knowledge Base

Build a scheduled Spojit workflow that lists your Shopify products, turns each one into a clean document, and embeds them into a persistent Knowledge collection so support staff can ask plain-language questions about product details.

What This Integration Does

Support teams waste time digging through the admin to confirm a fabric, a warranty term, a variant price, or whether an item is active. This workflow keeps a searchable Knowledge collection in sync with your Shopify catalog, so anyone (or any downstream workflow) can ask "What is the return window on the Trailhead jacket?" and get an answer grounded in your actual product data instead of a guess. The collection is workspace-scoped, so once it is built every workflow you own can query it.

The run model is a Schedule trigger: on a cron you choose, the workflow pages through shopify products, reshapes each product into a plain-text document, and embeds it into a persistent collection in Spojit's Knowledge section. Embedding the same file name overwrites the previous version, so re-runs refresh existing products in place rather than piling up duplicates. The collection persists between runs, accumulating and updating coverage of your catalog over time.

Prerequisites

A shopify connection added under Connections -> Add connection, with read access to products.
A persistent Knowledge collection created ahead of time. In the sidebar open Knowledge, choose New Collection, name it (for example shopify-product-kb), and note the embedding model you pick: you will reuse it for every embed and query.
A rough idea of catalog size so you can set a sensible page size and cron frequency (a few hundred products refreshes comfortably; very large catalogs warrant a narrower query).
Optional: a list of the support questions you expect, so you can decide which fields to include in each document.

Step 1: Add a Schedule trigger

Start a new workflow and set the Trigger node type to Schedule. Enter a 5-field Unix cron expression and an IANA timezone. For a refresh every weekday at 6am Sydney time, use:

cron:     0 6 * * 1-5
timezone: Australia/Sydney

A single Schedule trigger can hold multiple schedules if you want, for example, both a morning and an evening refresh. The trigger output is { scheduledAt }, which you do not need downstream here: the workflow simply runs the catalog sync each time it fires.

Step 2: List products from Shopify

Add a Connector node in Direct mode, choose the shopify connector, and select the list-products tool. Map these inputs:

query: a Shopify search filter to scope the run, for example status:active so draft and archived items are skipped.
first: page size, up to 250 (default 20). Start with 50 while testing.
after: leave blank on the first page; on later pages pass the cursor from the previous page's pageInfo.endCursor.

The result is a paginated list of products plus a pageInfo object that tells you whether more pages remain. If your catalog fits in one page you can stop here; for larger catalogs see the pagination note in Tips.

Step 3: Loop over the products

Add a Loop node in ForEach mode and point it at the list of products from the previous step, for example {{ list_products.data.products }} (match the variable name and shape to your list-products output). Each iteration exposes the current product as a loop item, for instance {{ product }}. Everything in the loop body runs once per product, building and embedding one document at a time.

Step 4: Transform each product into a document

Inside the loop, add a Transform node to reshape the product into a clean, readable block of text that embeds well. Pull only the fields support actually asks about (title, vendor, type, status, price, variant names, key description points) and write them as labelled lines. A plain-text document such as this works well:

Product: {{ product.title }}
Vendor: {{ product.vendor }}
Type: {{ product.productType }}
Status: {{ product.status }}
Price: {{ product.priceRange }}
Variants: {{ product.variants }}

Description:
{{ product.description }}

Keeping the document tidy and field-labelled gives the Knowledge node clean chunks to embed, which makes later answers more accurate. Store the result in an output variable such as doc_text.

Step 5: Embed the document into your collection

Still inside the loop, add a Knowledge node in Embed mode. Configure it:

Collection: select your persistent collection, shopify-product-kb (not Transient: you want this to last between runs).
File Name: a stable, unique-per-product name so re-runs overwrite rather than duplicate, for example product-{{ product.id }}.txt.
Document Type: Plain Text.
Document Input: the text you built, for example {{ doc_text }}.
Embedding Model: the same model you chose when creating the collection.
Output Variable: capture the chunk count and metadata, for example embed_result.

Because embedding a file name that already exists overwrites it, products that change between runs are refreshed cleanly and products that are unchanged simply get re-stated.

Step 6: Query the knowledge base from a support workflow

Once the collection is populated, support staff (or another workflow) can ask questions. In a separate workflow, add a Knowledge node in Query mode, pick the same shopify-product-kb collection, and supply a Prompt, a Model for synthesis, a Result Count (default 5), and an Output Variable. For a structured answer, attach a Response Schema so the output is reliable JSON:

Prompt: What is the price and return policy for the Trailhead jacket?
Result Count: 5

You can drive that query from a Webhook, an Email trigger, or even ask Miraxa, the intelligent layer across your automation, to scaffold the query workflow for you in the Workflow Designer.

Tips

For catalogs larger than one page, wrap Steps 2 to 5 so the workflow re-calls list-products with after set to the previous page's pageInfo.endCursor until no more pages remain, using a Loop in While mode keyed on whether another page exists.
Use the query input to keep runs lean: status:active, or updated_at:>2024-01-01-style filters mean you only re-embed what matters.
Always embed and query a collection with the same embedding model. Mixing models in one collection produces poor matches.
For a one-off "embed this single product then ask about it and discard" check, use a Transient collection instead of the persistent one, so nothing is stored after the run.

Common Pitfalls

Changing the File Name pattern between runs (for example switching from title-based to id-based names) defeats overwrite and creates duplicate documents. Pick a stable, unique key like product-{{ product.id }}.txt and keep it.
Setting first above 250 fails: Shopify caps the page size at 250 per call.
Forgetting the after cursor means you only ever embed the first page, silently leaving most of the catalog out of the knowledge base.
Cron is evaluated in the timezone you set, not the viewer's: a job set to 0 6 * * 1-5 in Australia/Sydney fires at Sydney 6am regardless of where the run is reviewed.

Testing

Before scheduling, narrow the scope and run once by hand. Set query to something tiny such as vendor:YourTestVendor and first to 5, then open the workflow and use the Run button (or temporarily switch the trigger to Manual). Confirm the loop iterates the expected number of times, the Transform output reads cleanly, and the embed output variable reports a sensible chunk count. Open the collection in the Knowledge section to verify the documents appear with status READY, then run a Query node with a known question to confirm the answer is grounded in your data. Once that looks right, widen the query and enable the schedule.