How do preferences work?

At their core, preferences are simply a way to store information. They are similar to environment variables, except that they operate with several layers of permissions. Overview Each preference consists of two major components, a definition and instances. A preference definition along with all of its preference instances are together considered to be a preference. Definition The preference definition is like a blueprint. It defines the nature of the preference and is used to create the instances at the various locations. Even though it may define a default value, the definition itself is never retrieved or read as a preference. If there are no instances of this preference, there is no value. Site A preference instance created at the site location applies to everyone logged in to Teamcenter unless overridden. There can be only one site instance. Group Any preference instances created at the group location apply only to users who are currently logged in as that group, and they supersede site preferences. There can be one group instance created for each group. Role Any preference instances created at the role location apply only to users who are currently logged in as that role (regardless of group), and they supersede site and group preferences. There can be one role instance created for each role. User Any preference instances created at the user location apply only to that user, and they supersede site, group, and role preferences. There can be one user instance created for each user. Preference definition You use the preference definition to create the overall limits and restrictions on the preference as well as setting the default value. Think of this as an abstract template from which the preference itself will be instantiated. Following are the fields used to define a preference definition: Name The name of the preference. Naming patterns help organize the preferences and give an idea of what they do even before you read the description. See the list of existing preferences for examples. Protection Scope Determines where and by whom it can be instantiated. Type Specify the preference value type. Multiple Specify if this preference can hold multiple values. Description Explain the use of the preference. What does it control? What format is expected for the values? Etc. Value Specify the default value that an instance will contain when initially created. Environment Retrieve the value from an OS environment variable of the same name. Category Organize related preferences based on their category. There are many existing categories you can use, or you can create your own. Preference instance You create a preference instance from its definition. When you create a new instance of a preference it must belong to a location. This location specifies when it is active and its priority in the hierarchy. You cannot create a preference instance if the protection scope does not allow it. When referring to preference instances, it is common to shorten the phrase. For example, the preference instance in the Engineering group location is commonly referred to as the Engineering group preference. When you create a new preference, you specify two things: Location Locations are where the preference instances reside. You can create preference instances at the following locations: User Role Group Site / System Value You can keep the default value from the definition or specify a new one. Preference locations User This assigns the instance to a specific user. These are commonly the preferences that Teamcenter uses to track things like column widths in the rich client, or most recently searched text, for example. Although you can control your active preferences like style sheet registration down to the user level, it is normally recommended that you keep those kinds of settings to the Group level or higher. It makes things easier when people move in and out of groups and roles. Role You can control the behavior based on a user's role. This is handy for things such as style sheets. Keep the consumer's page simple while being able to provide the information the author or approver needs. Group Similar to the Role location, you can control the behavior at the next step up, at the group level. Site / System Preferences created at these locations apply to everyone. This is typically where you instantiate preferences that control system-wide behavior or default behavior that can be overridden at the group, role, or user level. Site preferences only allow a single instance, but a dba can change the protection scope of a site preference to something else. System preferences do not allow their protection scope to be changed, even by a dba. In all other ways, they behave like a site preference. Caution An existing non-system preference may be changed into a system preference by a dba, but once it has been changed, it cannot be changed back. If you want to change it, it must be deleted and re-created. Customer-facing preferences You control an aspect of the UI or behavior directly by making changes to the preference. Examples of these preferences are configuring default paste relations, which style sheets are used in a given situation, or how the Dispatcher handles certain file types. Internal preferences Teamcenter uses preferences extensively to remember application parameters, like column width. Even though you can see and possibly modify the values of these preferences, it is not advised to do so.