PIM-Light: structured product data

Most powersport retailers run their catalogs in something between 'a spreadsheet' and 'a real PIM'. PowersportOS sits closer to the PIM end without the integration cost, every part carries the structured fields needed to publish a rich product page, push complete data to Shopify, and feed downstream systems like ERPs or invoicing software. We call this PIM-Light because it's not trying to be Akeneo, just trying to be enough.

What's structured

Every Part (central) and TenantPart (tenant-owned) carries the same set of fields:

Identification: Part number (canonical SKU), brand, name. The minimum a part needs to exist.
Description (HTML): Sanitised HTML body, server-side filtered through a whitelist (paragraphs, headings, lists, links, images, tables). CSV importer auto-detects plain text and wraps it in paragraphs. Matches Shopify's body_html shape so the product push lands clean HTML on the merchant side.
Category: Both a free-text legacy field and a foreign key into the PartCategory tree. Three-level tree (Engine → Air filters → Pre-filter, etc.) editable in the admin. Storefront filtering and faceting reads the tree.
Dimensions: Weight (kg), length / width / height (cm). Drives shipping calculators and Shopify product-level weight + size fields.
EAN / barcode: 13-digit GTIN where applicable, free-text otherwise. Drives barcode-scan flows and EAN-13 label rendering.
OEM cross-references: Multi-OEM table. Each Part can list arbitrary many OEM part numbers it replaces, each with the OE brand. Primary OEM (order=0) gets surfaced on storefront search; full list shows on the product detail page.
Country of origin: ISO code or free-text. Customs documentation, 'Made in Sweden' badges, supplier-origin filtering.
Multi-image gallery: ProductMedia table, ordered, primary-flagged, alt-text per image. Bulk-upload via the part detail page. Storefront API exposes the full gallery for theme rendering.
Bin / warehouse location: Free-text per-tenant per-part. Surfaces on labels. Each Multi-Store child carries its own bin independent of the parent.
Lifecycle status: Draft / Active / Deprecated / Discontinued. Optional 'replaced by' pointer to a successor SKU.
Asset storage: Images + manuals stored in our Hetzner bucket. Customer-supplied URLs auto-cached on CSV import. See the asset storage doc.

Why this matters: Shopify product push

The strategic value of structured data shows up the moment we push products into a customer's Shopify store. Every field above maps to a Shopify product field, so a single push produces a complete, rich product page rather than a stub the merchant has to finish by hand. See the product push doc for the full mapping and operational behaviour.

Field-to-field mapping:

PowersportOS field: Shopify field
Part.name: product.title
Part.description (HTML): product.body_html
Brand.name: product.vendor
Category (tree): product.product_type or collections
ProductMedia gallery: product.images
Dimensions + weight: variant fields
EAN: variant.barcode
OEM cross-references: metafields
Country of origin: metafield + customs metadata

Without PIM-Light, every customer would have to maintain a parallel data set in Shopify and risk drift between the two. With it, PowersportOS becomes the single source of truth and Shopify is a downstream consumer.

Editing surfaces

Four places where PIM data gets entered or maintained:

Central catalog (admin). Maintained by PowersportOS staff for shared brands. Every dealer activating a brand inherits the full PIM data.
Managed brands / managed parts (data providers, manufacturers, distributors). Delegated write access to the central catalog scoped per brand. The brand owner curates their own data directly through the portal, no admin in the loop. See Data ingest for the permission model.
Customer portal Part detail page. Per-tenant editing for TenantParts (tenant's own proprietary SKUs). PIM-grade form with tabs for general / media / cross-refs.
Bulk CSV import. All PIM fields available as CSV columns. Idempotent re-import. See the CSV format doc.

What's deliberately not in v1

Localised text per market. Description is one HTML body per part, not one-per-language. Shopify handles localisation at the theme layer for now.
Workflow approval. Edit-and-save is one step; there's no draft-then-publish gating. Add when a multi-user customer needs it.
Attribute schemas per category. Categories don't enforce a per-category set of expected attributes (engine displacement, voltage, thread size, etc.). The structured fields are universal; specialised attributes can ride on the description for now. Real attribute schemas come in v2 when a customer hits the limit.
Bulk media operations. Multi-image upload is per-part. No bulk replace-all-by-CSV for the gallery yet.

← Previous Internal YMM Lookup Next Data ingest