Product fields are the individual data points that make up your product records — things like product name, ingredients, serving size, barcode, or front-of-pack claims. Defining them well means your product data is consistent, validated, and ready to publish across all your channels.

Choosing the right field type

The field type controls what can be entered and how it is validated. Choose the most specific type that fits the data:

• Text — for names, descriptions, and free-form written content
• Number / Measurement — for quantities, weights, serving sizes, and dimensions
• Select / Dropdown — for controlled lists where the value must be one of a defined set, such as product status or flavour options. Strongly recommended over free text for anything with a fixed set of values.
• Identifier — for SKUs, SCINs, barcodes, and other unique codes
• Table — for repeatable rows of data such as a nutritional panel or specification table
• Media — for linking image or document slots to assets

When to make a field required

Only mark a field as required if it genuinely must be completed before the product can be published. Over-requiring fields slows editors down and leads to workarounds like filling in placeholder data just to clear a validation error.

Scope: global versus localised

Some fields should have the same value everywhere — a barcode, for example. Others need to vary by market or language — marketing copy or legal disclaimers. When setting up a field:

• Use global for data that never changes regardless of market or language
• Use localisable only for fields where the content genuinely differs between languages
• Use market or channel scoped for fields that need different values per region or sales endpoint

Keeping scope as simple as possible prevents unnecessary complexity in the editor.

Validation

Add validation to catch errors at entry time, before bad data gets published. Common options include character limits, required format — for example, a barcode must be 13 digits — and uniqueness constraints for identifiers. Only apply uniqueness constraints where the data truly needs to be unique, as applying them too broadly creates unnecessary friction for editors.

Ongoing field quality

Field definitions need occasional review. Audit your fields periodically to look for fields with low fill rates, fields where data quality is inconsistent, and fields that were added for a specific project but are no longer relevant.