Define core product fields with reusable field schemas

These fields align with those required for Article, so we’ll define a CoreContent reusable field schema (RFS). This schema contains the core information and is reusable across different content types if needed.

Here’s the structure of our CoreContent schema:

• CoreContentTitle:
  • Field caption: Title
  • Data type: Text
  • Form component: Text input
  • Maximum length: 200 characters
  • Text below the input: “Enter a clear and descriptive item name for customers.”
• CoreContentShortDescription
  • Data type: Text
  • Field caption: Short description
  • Form component: Text area
  • Maximum length: 500 characters
  • Text below the input: “Provide a brief summary for listings and search results. Focus on key benefits.”
• CoreContentThumbnailImage
  • Data type: Pages and reusable content
  • Field caption: Core taxonomy
  • UI component: Combined content selector
  • Allowed content types: Asset (Image)
  • Maximum items: 1
  • Text below the input: “Choose the main image for listings and search results.”
• CoreContentTaxonomyTags
  • Data type: Taxonomy
  • Form component: Tag selector
  • Allowed tags: Core taxonomy
  • Text below the input: “Choose tags to help customers filter and search for this item.”

Follow recommended field naming conventions

Notice that all fields in the CoreContent schema start with “CoreContent” prefix. This naming convention serves several important purposes in XbyK:

• Prevents database column name conflicts by ensuring each field name is unique. Xperience stores content type data in SQL database tables. When you add a reusable field schema to a content type, the schema’s fields become columns in ContentItemCommonData database table. If you add multiple schemas to the same content type and they have fields with identical names (like Name, Title, or Description), you’ll encounter naming conflicts. By prefixing fields with the schema name, you ensure uniqueness. Even if multiple schemas require a Title field, it becomes CoreContentTitle, ManufacturerTitle, or CategoryTitle.
• Improves code readability and maintainability by incidating the schema to which the field belongs. When developers query content items and access field values in code, the prefix makes it immediately clear which schema a field belongs to. This clarity is especially valuable in large projects with many content types and schemas.
• Appears consistently in queries and APIs. Whether developers retrieve content through the Content Query or Content Retriever API, Xperience GraphQL, or custom REST endpoints, the prefixed field names are consistent, making it easier to understand data structure across different contexts.

Reusable field schemas help editors in the admin UI

When editors create a product using a content type that includes the CoreContent schema, they’ll see these fields grouped together in the editing form. Xperience displays the schema name as a header of a collapsible section. This helps editors understand which fields belong together conceptually.

This image illustrates how reusable field schemas work together with dedicated product fields within the Product SKU model. Core fields, such as title, pricing, and product attributes, are defined as reusable schemas to ensure consistency across different product content types. SKU-specific fields store unique product data. We’ll dive into how this composition approach keeps your product data structured, maintainable, and easy to reuse.

Separate core content data from product-specific fields

Though products are, from information-architecture perspective, semantically independent entities, other content types (and independent entities or things, such as Article, Person , or Organization ) share the same data fields, including name, description, category or representing image.

In many commerce implementations, separating product-specific data from general content into a dedicated schema can be beneficial. This schema can be included in all relevant content types.

Your Product content type will then share this schema fields with other content types. This approach simplifies queries for developers, particularly in marketing-heavy stores. Campaigns, seasonal content, and editorial features can reference products without requiring product-specific data.

For example, editors can use the same Card widget to display core product data in a Summer Pet Care Guide campaign page, or alongside with core data from a Top 10 Dog Toys article.

Separating product data (e.g., SKU, price, inventory, and specifications) from repurposable marketing content creates a cleaner data structure. This simplifies queries for developers and presentation components for editors.