Module: Commerce content modeling

11 of 38 Pages

Model SKU details as a reusable field schema

✖
Copy to clipboard

The Content modeling MCP server initially generated a simple SKU field directly on the Product content type. This works for basic scenarios, but as commerce implementations grow, you’ll often need more sophisticated SKU management across multiple product types.

Besides SKU identification, products often also require additional identifiers for inventory management, barcode scanning, manufacturer part numbers, or integration with external systems. To avoid duplication and inconsistency, you can create a dedicated ProductSKU reusable field schema. This schema will include fields ProductSKUCode, ProductSKUBarcodeEAN, ProductSKUBarcodeUPC, ProductSKUMPN, ProductSKUExternalId, and other project-specific fields.

When a simple SKU field is enough

Not every implementation needs the full ProductSKU schema. For simple catalogs with no integration requirements, a single SKU field may suffice.

When ProductSKU should be a reusable schema

The CoreContentSchema defined above supports all content, including non-product content types, such as articles, featured content, or press releases.

A dedicated ProductSKU RFS offers several advantages:

  • Cross-type consistency. Whether you’re working with a dog collar (Product) or a fish (Pet), SKU-related data is captured and structured identically. This consistency makes queries, integrations, and reporting significantly easier.
  • Centralized evolution. When you need to add new identifier types, such as GTIN for Google Shopping or ISBN for pet care books, you update the ProductSKU schema once, and all content types using it automatically gain the new field.
  • Integration readiness. External systems (for example, inventory management, POS, or marketplaces) expect standardized product identifiers. A reusable schema ensures your content model speaks the same language as these systems.
  • Integration signal. Use the SKU schema to signal to integrations. Developers can build mechanism that determines when event handlers or scheduled tasks should propagate product updates to inventory, pricing, or other external systems.

If you answer “yes” to any of these questions, consider using the ProductSKU schema approach:

  • Do multiple product types require SKU identification?
  • Will you integrate with inventory, ERP, or marketplace systems?
  • Do you need barcode scanning capabilities?
  • Do you sell products from multiple manufacturers with unique part numbers?
  • Might you need additional identifier types in the future?

For Pawsome Pets, we chose a simple ProductSKU field on the Product content type for simplicity.

When finalizing your project’s Product fields, aim to balance simplicity with scalability. Starting too simple, you may face technical debt later. Overengineer early can slow your team. Aim for a solution that fits your current needs and allows for future growth.

Consider the above questions before defaulting to an overly simple commerce content type model.

When to use reusable field schema vs. direct content type fields

You might wonder when to use a reusable field schema versus adding fields directly to a content type. Here’s the general guidance:

Use RFS when:

Use direct fields when:
  • The fields are reused across multiple content types.
  • You want to maintain consistency in how certain data is captured.
  • The fields form a logical grouping relevant across contexts.
  • You expect that the schema evolves over time.
  • The field is unique to a single content type.
  • The field serves a specific, non-replicable purpose.
  • You need maximum flexibility without schema constraints.

11 of 38