Managing catalogs

What a catalog is

A catalog is your own product data, loaded into the platform so it can be searched by meaning rather than by exact keyword. A shopper asking for "something warm for hiking in the rain" gets sensible results without those words appearing anywhere in your product titles.

The Catalogs page is where you define the shape of that data. Loading the actual records, and searching them, happens from a workflow using the Catalog connector — there is no separate API to call.

Creating a catalog

Catalogs → New catalog asks for four things:

• Name — what you'll call it in the workflow editor.
• Description — optional.
• Primary key field — the field that uniquely identifies a record, usually sku. Choose carefully: this decides how updates match existing records, and it cannot be changed later.
• Restrict visibility per customer and Per-customer pricing — two switches, covered under Visibility and pricing below. Leave them off if every customer sees the same catalogue at the same price.

The Schema tab

Fields

Each field has a key (what your data calls it), a label, a type, and four role switches that decide what the platform does with it:

• Search text — include this field's value in the text that gets embedded for meaning-search. Titles, descriptions and category names belong here; SKUs and timestamps do not.
• Filterable — allow exact filtering on this field at search time (brand = Nike, price <= 100). Limited to 8 fields per catalog, because each one occupies a slot in the search index.
• Returnable — include this field in search results. Everything is stored either way; this controls what comes back.
• Keyword — also match this field by exact keyword alongside meaning-search. Useful for brand and model names, where somebody typing the exact string expects an exact hit.

Once a field has been saved, its key and type are fixed and the editor locks them. Changing either would orphan every record already stored under the old shape. To change a field's type, add a new field and migrate.

Search text template

Controls exactly what text gets embedded per record. The default joins every field marked Search text; edit it when you want more control — for example putting the brand and title first, or adding fixed wording around a value.

What goes in here matters more than any other setting on the page. It is the only thing meaning-search actually reads.

Re-indexing

Changing the search text template or the Search text roles means existing records no longer reflect the current setup, and the page shows an amber "Items need re-indexing" banner with an estimate of how long it will take.

Press Re-index now to rebuild. Search keeps working throughout, returning results based on the old text until each record is reprocessed, and you can leave the page while it runs. Changing a price or a Returnable role never triggers this — only the text that gets embedded does.

The Records tab

Shows what is actually in the catalog: one row per record, with the fields from your schema as columns.

• Find by key searches the start of an item key, so SKU-01 matches SKU-010 through SKU-019. It does not search names or descriptions.
• Status filters by indexing state:
  • Indexed — searchable now.
  • Indexing — stored, but not yet findable by meaning-search.
  • Failed — embedding failed; hover the badge for the reason. These records are stored but will never appear in search results until re-indexed.
  • Skipped — nothing to embed, usually an empty search text template result.
• Records are listed most recently updated first, which is what you want right after a sync.

This tab is read-only. Records are created, updated and deleted from a workflow through the Catalog connector — that way every change to your catalog goes through the same auth, logging and execution history as the rest of your integrations.

If a search isn't returning something you expect, this tab is the first place to look: the record may be missing, or present but stuck at Indexing or Failed.

Visibility and pricing

Two optional features, set when you create the catalog. They solve the B2B case where one product means different things to different customers.

Restrict visibility per customer lets a record carry visibility terms — grants that say who may see it, and denials that hide it from specific customers. A record with no terms is visible to everyone. This is how one product disappears entirely for one customer without affecting anyone else.

Per-customer pricing lets the same record carry a different price per context — a customer, a price list, a region. At search time you supply those contexts most-specific-first and the first one with a price wins, so Customer A sees £10 and Customer B sees £12 from the same catalog.

Prices are stored separately from the records themselves, so updating a price never triggers a re-index. Both features are driven entirely from the workflow that loads your data; see the connector page for the exact fields.

Typical setup

1. Create the catalog and choose the primary key.
2. Add your fields and set their roles — be deliberate about Search text.
3. Build a workflow that fetches products from your source system and writes them with Upsert Catalog Items.
4. Watch the Records tab until the first batch reaches Indexed.
5. Add a Search Catalog step, or expose the catalog to an assistant via an MCP server.
6. Schedule the sync workflow, using the sync-state actions so each run only fetches what changed.

Deleting a catalog

Deleting removes the catalog, every record in it, and every price attached to those records. It cannot be undone, and any workflow step still pointing at that catalog will start failing.