Background

Driven by requests of companies in the fashion industry an optional additional tier for maintaining product data has been introduced and is available in Product 360 starting with version 7.
Apparel companies typically have their processes aligned with respect to three tiers, oftentimes due to their legacy systems which are also set up in this way and thus their processes aligned accordingly.

The background of this requirement is to maintain data which is relevant for all items below on a higher level, which leads to the fact that the data only has to be maintained once. With this approach a faster data maintenance can be achieved, it is made sure that all items below this variant are consistent, and that it is possible to set specific rights for variant fields. Also, the data does not need to be stored redundantly, which could result in a higher performance.

Typical examples of individual levels include different cuts for the product level, containing detailed text information and attributes, with the different color options at the variant level, including the associated media assets, then the sizes of the clothing with the unique order number and price information typically on item level. The variants entity contains the full range of functions of the familiar entities, for example for assignment of media assets, references, features, attributes, and own rights.

	Example of information
	General descriptions, attributes (washing instructions, material...), general relationships
	Media assets, variant-specific descriptions, variant-specific relationships
	Sizes, order number, dimensions, prices

Benefits

Faster Data maintenance and faster time to market
- e.g. media assets only need to be assigned to the variant, not to multiple items
Better data quality and consistency
- e.g. it is ensured that all items belonging to the same variant have the same media asset
Better rights/roles management
- possibility to set specific permissions on variant editing

When to use the three-tier product paradigm?

When evaluating the applicability of the 3-tier model it is very important to have a look at where the data comes from and where the data goes to. Is the source of the data available in 3-tiers as well? Are the target systems (e.g. eCommerce system) able to handle 3-tier data as well? If this is not the case then it can be complicated to split or aggregate the data and the effort should be evaluated holistically.

Some check questions can also be

Do you need a rights model for the variant tier?
Do you need to create relationships between variants and other objects?
Do you need to store media assets on the variant tier?

If you do not need to explicitly store information on the variant level it is recommended not to use the three-tier paradigm because it can introduce additional complexity.
Alternatively using user interface options like grouping on specific attributes and using batch editing can be a meaningful solution in many cases as well.

What to keep in mind

No mixed mode is supported, only 2-tier or 3-tier
An item is only allowed to have one higher-level variant, a variant only one higher-level product
Using the 3-tier model increases complexity in several areas for the user and may worsen the usability.
Keep in mind that in the Desktop UI there are no generic views, so one additional view to everywhere where product/item views are available today.
Data access gets more complicated, may need customization for data aggregation and splitting, e.g. accessing higher-level sub-entities in export