Skip to main content

LoVs: how they work, design rules, and best practices

Lists of Values (LoVs) define the permitted options for simpleselect and multiselect attributes in SKULaunch. They ensure consistent, clean, structured data that can be enriched, validated, searched and exported reliably.

S
Written by SKULaunch Support
Updated over 4 months ago

What LoVs are

A List of Values is a controlled set of allowed options for an attribute.

Examples:

  • Flavour → Chicken, Beef, Tuna, Mixed

  • Food Format → Dry, Wet, Treat

  • Voltage → 110V, 240V

  • Wood Species → Pine, Oak, Spruce

When a user or supplier selects a value, it must match exactly one of the LoV items.

Where LoVs are used

LoVs power two attribute types:

  1. Simpleselect – only one value can be chosen

  2. Multiselect – multiple values can be chosen

LoVs support:

  • Enrichment accuracy

  • Data standardisation

  • Supplier submission

  • Search and filtering

  • Channel mapping

  • Analytics and reporting

How LoVs behave in SKULaunch

1. LoVs enforce controlled vocabulary

Only values in the LoV can be assigned.
This prevents variation such as:

  • Chicken vs chicken

  • 240 V vs 240V vs 240 Volt

  • Adult vs Adults

Every record uses exactly the same canonical value.

2. AI normalises extracted values

SKULaunch AI uses LoVs to map extracted text to the nearest valid option.

Examples:

  • “with beef” → Beef

  • “suitable for senior dogs” → Senior

  • “poultry flavour” → Chicken (if allowed as synonym) or flagged for review

LoVs dramatically improve enrichment quality.

3. LoVs drive validation

If an incoming value (from enrichment, uploads or suppliers) does not match a LoV option:

  • It cannot be saved automatically

  • It appears as an error or requires user review

  • AI attempts mapping but does not invent new values

4. LoVs export cleanly

Downstream systems such as PIMs, eCommerce, ERPs and channels receive consistent, predictable values.

If channel-specific mappings are defined (optional), SKULaunch can translate LoVs into channel equivalents.

5. LoVs apply uniformly across inherited schemas

A simpleselect attribute with an LoV:

  • Inherits the same value list across all families

  • Cannot have different lists per family

  • Guarantees consistent interpretation across categories

Design rules for strong LoVs

A good LoV is small, clear and unambiguous.
Here are the core design rules.

1. Values must be mutually exclusive

Avoid overlapping meanings.

Bad example:

  • Large

  • Extra Large

  • Big

Good example:

  • Small

  • Medium

  • Large

  • Extra Large

2. Values must be unambiguous

If the meaning is not obvious, the AI cannot map it reliably, and suppliers cannot choose confidently.

Bad example:

  • Fresh

  • Premium

  • Special

Good example:

  • Raw

  • Cooked

3. Values must reflect real product distinctions

Do not add values that have no practical difference.

Bad example:

Flavour:

  • Chicken

  • Chicken Mix

  • Chicken Blend

  • Chicken Selection

Unless these have specific meaning in your product domain, they introduce noise.

4. Values should be easy to map from real-world text

Good LoVs match the language found in:

  • Packaging

  • Product titles

  • Supplier data

  • Websites

If your LoV uses uncommon or internal naming, AI will struggle.

5. Avoid excessive granularity

More is not better.

A long LoV increases:

  • Supplier confusion

  • Mapping failures

  • AI misclassification risk

Keep lists tight and purposeful.

6. Avoid synonyms inside LoVs

If “Beef” and “Beef Meat” mean the same thing, pick one.
Synonyms should live in a mapping layer, not the LoV itself.

7. Use consistent style

Pick a style for all values:

  • Capitalisation

  • Spacing

  • Plural vs singular

  • Hyphenation

Consistency improves readability and downstream data quality.

Did this answer your question?