Dimension and Dimension Points Recommended Practices

While STEP is highly configurable for creating and maintaining dimension and dimension points, certain implementation standards apply. This topic outlines considerations to your system to handle dimension-dependent data.

Review the Dimension Recommendations and Dimension Warnings sections the bottom of this topic for points of interest and alternatives to additional dimensions.

Note: Never use more than three dimensions. Typically, only two should be used, though it is possible to even use only one—language.

Language Dimension

There must be a language dimension. This is the only dimension that is supported by the STEP translation tracking and translation workflow features. For more information on the translation functionality of STEP, refer to the Translations documentation.

Even if you do not use multiple languages, you must have a language dimension for the language in which you are maintaining your data. Choose a real language so that it is very clear what belongs there. The language dimension is special in STEP because it tracks changes between a source language and its translations. This means that there are no STEP tools to help users find instances where content in a country-dependent attribute value has changed and may need to be updated for other countries.

In many installations, only the language dimension point is required. Additional dimensions, such as country, are not needed if there is no country-specific data, such as warranty information that varies depending on which country a product is sold. The screenshot below shows a dimension hierarchy in System Setup and two contexts that only use the Language dimension.

Country Dimension

The Country dimension comes standard with STEP, but if you do not need it, remove it until you do.

You should only use a country dimension if the following conditions apply:

  • You have products that are sold in more than one country and there are a lot of attributes with different values because of the country they are sold in.
  • You have products that are sold in more than one country and there are a lot of references that are different because of the country they are sold in.
  • You are using the Stibo Systems GDSN solution, which requires that each target market references a context containing a language and country dimension.

If there are only a handful of attributes on products that are only sold in a few countries, use separate attributes to hold this information. For example, 'Description, English,' 'Description, German,' and so forth.

Additional references might also be used if they relate to information that varies by country. For example, a product could reference a PDF document and the document contains different information in some countries. Instead of making the reference dimension-dependent, you could make separate reference types ('Warranty, United States' and 'Warranty, Canada'). For information on dimension-dependent references, refer to the Dimension Dependent Reference and Link Types topic.

Business Unit Dimension

Business unit dimensions are sometimes used in larger enterprise implementations, as well as in cases where customers start out with a STEP implementation and then acquire another business.

Business unit dimensions may be needed for enterprise-wide implementations if the following conditions apply:

  • The exact same products, with the same internal ID, are sold by more than one business unit.
  • Each business unit must share the same pool of attributes, and there are no clear 'owners' of the attributes. For example, an attribute like 'Description' is used for products across all business units instead of there being separate attributes for each business unit—'Acme Shoes Description,' 'Acme Electronics Description,' or 'Acme Clothing Description.'

Even if these conditions apply, it should not be an automatic decision to use a business unit dimension. Different customer-facing part numbers, for example, can be stored in separate attributes. If part numbers are different based on the business unit selling the products, you might need a business unit dimension, but this is not enough justification on its own to do so.

Market Dimension

Because market dimensions are not recommended, this section mainly addresses them to provide alternatives to their use.

Any requirements for market-dependent data are typically for a small number of attributes or references, which can be handled by a less-complex approach of additional attributes and/or references.

  • Most market-specific attributes are typically separate attributes.

  • Market-specific asset references can be handled by separate reference types.

  • Whether using dimensions or separate attributes, people who maintain market-specific attributes are only able to partially approve their own content.

Alternatives to market dimensions are to:

  • Use separate attributes, for example for web copy, print copy, and so forth.

  • Use separate reference types, based on different markets.

  • Group the reference types for visual separation.

Dimension Recommendations

The following are recommendations for dimensions:

  • Use as few dimensions as possible since dimensions affect usability.

    Dimension-dependent data is a good concept but should not be taken too far.

    The more dimensions there are, the more likely it is that users will have to go back and forth between contexts. When users forget to change contexts appropriately and data is added in the wrong dimension, it can potentially be a long time before the mistake is realized. There is no easy way to find the data that should be corrected.

    When using an import, if a lot of data must be entered while working in one context, and then some of that data must also be entered in another context, data ends up in the wrong place if the user forgets to break up the information into separate load files, or if they forget to change context appropriately.

  • In most circumstances, dimension points should be created at the same level:

    However, there may be a need to have parent / child relationships between dimensions to maintain many versions of an 'almost the same' language, as pictured below. In this type of setup, parent values from the top-level dimension will be inherited by the child dimensions. If this is implemented, there must be clear ownership of the parent language. Otherwise, do not use one.

For more information on use cases and the value inheritance of parent / child dimensions and attribute values, refer to the Dimension Dependent Attributes topic.

  • Be consistent across all dimension points and use IDs based on ISO standards. More information about these standards can be found on the web.

    For languages, use IDs based on the ISO 639-1 Language Code (2 letter) + ISO 3166 alpha-2 Country Code. For example, US English: en-US.

    For countries, use IDs based on the ISO 3166 alpha-2 Country Codes. For example, United States: US

Dimension Warnings

The following are warnings for dimensions.

  • Do not introduce a dimension unless there is strong justification for it.

  • Do not use a dimension for any aspect of data that is temporary, such as a website dimension, a print publication dimension, or promotions dimension.

  • Do not use an All dimension point in a context. Nobody speaks All Languages, nobody lives in All Countries, and nobody will maintain All.

Note: When content is not dimension-dependent it is already stored in the Language Root and Country Root dimension points.

Alternatives to Additional Dimensions

As an alternative to creating more dimensions, consider using additional attributes or additional reference types, which are acceptable if you only have a small amount of information that will vary by language or country.

Arguments for Additional Attributes

Arguments for Additional Dimensions

This is a simple approach for users to understand.

Using the same attributes in layers enables re-use of integrations, saved imports, saved exports, and Web UI screens.

Users can compare values for all versions side-by-side in an Excel file.

Users can compare values for a single attribute across dimensions using the STEP context mode. Refer to the Context Mode View topic.

More dimensions drive more contexts. More contexts mean users have to be aware of which context they should work in, causing a high risk that users make mistakes and put data in the wrong context.

Fewer attributes. Separate attributes for each dimension could mean many hundreds more attributes.

More dimensions drive multidimensional attributes, which are to be avoided.

 

To load data via Excel, it is easier to add more attribute columns to Excel than it is to separate Excel files when some of the data has to be loaded to a different context.