Context Recommended Practices

Though STEP is highly configurable with regard to the creation and maintenance of contexts, certain implementation standards apply to how they are created and implemented. This topic outlines some considerations to keep in mind when deciding how to configure your system to handle dimension-dependent data.

Context Do's

• Plan for future change—use IDs that will still make sense when situations change. The language + country will not make sense if you add another dimension later on.
• Use a generic ID and do not use the ID as the name. Change the name to be readable by users. Unlike most objects in STEP, there is no option to auto-generate Context IDs.

• Suggest IDs that are future safe. For example, if you only start out with a language and then a country dimension is added at some point in the future, 'EN' will no longer make sense. You could delete the EN context and create a new one (EN US), but that could mean that downstream systems that are receiving feeds may need to make adjustments to accept the new files, or, for print implementations, there may have been created hundreds and hundreds of InDesign pages created that have the context ID stored in the page files.

Context Don'ts

• Do not create a context that will not be used right away. Create only the combination of dimensions that you need.
• Do not use an All level in a context. Pick a real language and a real country.
• Avoid asking users to work in multiple contexts. There is a very high risk that someone will accidentally enter content in the wrong context, and it is very difficult to find these situations and correct them.

Global Context

• Do not use a global context. Nobody should work in global, which results in unnecessarily inherited values. See the Dimension Dependent Attributes topic here for more information on value inheritance in dimension-dependent attributes.

A global context is where the All Languages + All Countries dimensions would be used. Nobody speaks All and nobody lives in All, so no one should maintain data there.

Problems that could be caused by using a global context include:

• A user might log in to a global context to create some attributes. They also do some sort of data maintenance in STEP. They may forget to switch contexts before entering language-dependent data in English and, if so, they have stored that information in the 'All' level instead of the 'English' level. That is not where it belongs, and it should be moved.
• A user may forget that they are in the global context and exports data to send to someone. This file would not contain any of the language- or country-dependent data, so the file is incomplete.

Deleting the Global Context

If a global context already exists on your system—and there is no content whatsoever in it—then delete it.

Important: If a global context already exists on your system—and it contains content—do not delete it unless you plan to first move the data into a different context. Deleting a global context that contains data will affect ALL data in the context; not just attribute values, but LOV values, metadata on links, references, assets, etc.

Removing a global context from an existing system requires more than a small amount of analysis and possibly significant cleanup / rework (repushing assets, for example). Additional reasons to not to delete a global context with data include:

• If the data is inherited from the global context by other contexts, though the data will still exist, it will likely no longer be editable.
• If the context is assigned to any configurations (integration end points, export, import, etc.), then these configurations will no longer be valid.
• Assets, if dimension dependent, are also affected, especially in a print initiative where images are pushed to folder structures corresponding to the dimension. This means that functions such as 'Replace Asset Content' would be impossible.