Purpose of ready-made product fields

Not all product data should be modeled as Attributes. A product has built-in fields that have their own storage logic and impact on things like price, balance, availability, store visibility, shipping, or integrations. Always use a built-in product field when one exists.

Ready-made product fields and attribute codes in practice

Pre-built product fields control the actual functionality of the product, while Attributes supplement the product with additional information that describes it. If the same information is stored in both a pre-built field and an Attribute, two competing values are created for maintenance. A transaction, filter, feed, or integration can then read a different value than the administrator corrects.

Keep SKU, Status, prices, taxes, balance, availability dates, shipping information, images, SEO information, Product Type, and product grouping in their own fields. Create an Attribute only for data that does not have its own ready-made field and that describes the product consistently across multiple products. The Attribute Code is a permanent internal identifier, not a replacement name for a ready-made product field.

Open the correct product tab

The product's right tab is opened from the Products page /products by selecting the product to be edited.

The finished product information is divided according to purpose:

• The overview includes the product's core identifiers and status.
• Descriptions include language-specific names, URLs, and texts.
• Pricing includes prices, tax bracket, packaging pricing, and discount structures.
• Availability includes purchase and visibility dates, as well as tickets.
• SEO includes fields intended for search engines.
• Media includes the main product image, additional images, and media links.
• The balance includes variants and Inventory lines.
• Shipping and Dimensions and Weights contain shipping calculation information.
• Advanced settings include Product Type and special trading behavior flags.
• Attributes contain additional descriptive information defined by the Attribute Family.

Basic product information and several restricted sections are autosaved, but some functions use their own save or confirmation. Always follow the section's status indicator and success message.

Tags, content, and SEO are ready-made fields

Product tags, content, and SEO are pre-built fields, so don't create an Attribute for the following core data:

• SKU , Status , Display Profile , Supplier ID , Manufacturer , and Order .
• Language-specific Name , URL , Short description , Description , Image description , and Comment guidelines .
• SEO Title , Search Phrase and Meta Description .
• Materials maintained in the finished material selection of the product.

The SKU identifies the product in the system and in integrations. The status controls the visibility of the product in the store. The URL and SEO fields form the content intended for search engines, and the language-specific descriptions are displayed in the selected store language. The Parallel Attribute does not change the behavior of these fields or replace the missing value.

Use Attribute for example, a technical standard, certificate, compatibility, or other classifying characteristic for which the product does not have a ready-made field.

Price, tax, and quantity logic are ready-made fields

Price, tax, and quantity logic affect the calculation, so they are not stored in text Attributes. Use fields on the Pricing tab, such as Base Price , Original Price , Special Price , Start Date , End Date , Tax Category , Purchase Price , Package Size , and Package Unit .

Also use the ready-made Group Discount, Quantity Discount Group, Volume Surcharge Group and Step Price structures in the same section. Minimum Quantity and Quantity Step control the customer's allowed order quantities. Base Balance and Actual Inventory Balance are ready-made product data, not Attributes.

The special price dates determine when the promotional price is valid. The tax category affects the tax calculated at checkout. The price, percentage, or tax rate written in an attribute does not contribute to these calculations and may therefore appear plausible but be functionally incorrect.

Balance, variants and packaging are part of the warehouse structure

Balance, variants, and packages belong to the inventory structure, so do not create an Attribute for a product or variant's balance, Inventory SKU, Barcode, Shelf, Reserved Quantity, or Incoming Quantity. These belong to the Inventory lines on the product's Balance tab.

When a customer's choice affects the SKU, balance, or price, use Product Options, Variants, and Inventory Lines. The Product Option Value defines the choice, the Variant identifies the value combination, and the Inventory Line stores the inventory quantity and line-specific information. An attribute can describe a technical characteristic related to the same product, but it does not replace the warehouse structure.

Package Size and Package Unit are part of pricing. Product and package Length , Width , Height , Weight , and Volumetric Weight are part of the Dimensions and Weights section. These values can be used to display unit price, shipping calculations, and integrations, so the parallel Attribute is not a functional equivalent.

Availability, visibility and product type are system logic

Availability, Visibility, and Product Type are system logic. Use the product's built-in Availability Date , In Stock Date , and Clearance Date fields, as well as the Free Shipping , Google Feed , and Hide from Guests toggles. They can prevent purchases, change store visibility, affect feed, or bypass shipping charges; the Attribute of the same name does not control these actions.

Product Type , Hide Grouped Products , Hide Selectors , Accessory Product , Customizable , Inventory Check , and other store behavior flags maintained in advanced settings are also pre-built system data. Product Group Membership, Main Product, Package Structure, and Product Option Selections are maintained in their own structures.

Do not attempt to change the type, grouping, purchasability, or visibility of a product using an Attribute. Use an Attribute only as additional descriptive information unless a separate implementation explicitly reads it into a business rule.

Media, editorial and integrations use their own fields

The Media tab of a product maintains the main product image, additional images, their language-specific descriptions, order, Option Binding, YouTube link, and other media links. The product image or image file reference is not part of the general Attribute if it is already processed by the Media function.

Product shipping price exceptions and shipping restriction groups are under the Shipping tab. Weight, product dimensions, packaging dimensions, and volumetric weight are under the Dimensions and weights section. This information can affect the shipping method selection and price calculation.

The Integration section includes API Model , API ID , and API Cost Center . The API Message displays the integration message saved for the product. Use these ready-made surfaces and Data Transfer Profiles; do not copy integration identifiers into general Attributes without the need specified in the integration agreement.

When is Attribute the right solution?

An attribute is the right solution when the information describes a product, is used consistently across multiple products, and does not have a ready-made product field. Good uses include technical standards, certificates, compatibility, surface treatment, or additional information specific to a product group.

An attribute can be Filterable , Compareable , Listable , Highlighted , Visible in store , or included in a product PDF. However, these usages do not make the Attribute a price, balance, SEO, availability, or shipping field.

If the information affects the version that the customer chooses to store, use Product Option and Variant. If the information affects calculation, visibility, routing, input, or integration, first find a corresponding ready-made field. Only create a new Attribute after you have verified that there is no ready-made structure.

Rename attribute code to permanent

The attribute code is named permanent because the Attribute Code is an internal identifier used in Data Transfer, filters, and integrations, for example. Choose a short and descriptive code that means one thing, does not contain spaces, and does not copy the name of a pre-made product field.

The code should remain unchanged after the attribute is used in products or integrations. The name translation can be changed to be more understandable for users, but changing the code is a separate migration. Do not infer reserved codes from the English field name alone; first determine if the information is already in the product's own editor.

There is no separate complete published list of all future or integration-specific reserved codes. A safe rule is simple: do not create a parallel Attribute for any data that already has a ready-made product field or its own system structure.

Mass change check

Mass change checking is done in Data Exchange /data-exchange when products or Attributes are changed using CSV files.

Choose a profile based on the structure you want to change. The product import profile handles out-of-the-box product fields, while the product attribute values profile identifies an Attribute by its Code. Don't add a column to your product attributes dataset just because it has the same name as an out-of-the-box product field.

Export the current data, check the preview field mappings, and fix any conflicts before executing. If the same data already exists in both the ready-made field and the Attribute, first decide on the canonical storage location, migrate the necessary data in a controlled manner, and remove the use of the parallel field from integrations and the maintenance process.