• Set a null security label value on objects that do not contain sensitive information. Setting a non-null informative marking is also acceptable. Objects with null security label values and non-null informative markings do not restrict access, which means your Windchill system will not need to verify that the user is an authorized participant.

• Use security labels only when one or more values restrict access to an object. Otherwise, use global attributes rather than non-null informative markings on an object. Security labels that are purely informative markings are not a replacement for global attributes.

• For objects that do contain sensitive information, add participants to the label value's authorized participant's group unless the participants only need access for a limited time. Agreements should be used only as an exception to a security label value restriction. While there is no limit to the amount of time an agreement can be active, agreements should not be used as the primary means to grant a large number of users access to a security-labeled object.

• All the name/value pairs applied to a business object are stored together in a single database column with a size limit of 4000. For standard security labels, keep the name attribute of the SecurityLabel element and the name attribute of the SecurityLabelValue element as short as possible as these values are not generally seen in the user interface. For more information, see Edit the Security Labels Configuration File. For custom security labels, keep the name attribute of the CustomSecurityLabel element and the internal custom security labels values as short as possible. You can use a custom translator to reduce the size of the internal values stored in the database. For more information, see Create a Custom Translator Class.

• Use caution when specifying an authorized participant for a security label value or an agreement. Specifying a group or an organization as an authorized participant gives those with permission to change group or organization membership control over who is authorized by the security label value or agreement. Make sure that you select groups and organizations whose membership can only be modified by administrators that should be allowed to extend access to objects with the security label value applied or that are associated with the agreement. For example, if you select a system group associated with a context team role as the authorized participant for an agreement, by default the context administrator is able to change the team membership and therefore also change who is an authorized participant for the agreement. Unless the context administrator is also an agreement administrator, the context administrator may not understand the impact of changing the team membership.

• The Select Authorized Related Changes step when creating or editing an agreement aids in managing agreement authorized objects. However, including large change objects as related change objects in an agreement can negatively impact Windchill performance.

• By default, all security labels are available as columns in the Object List table on the Edit Security Labels window. A custom table view can be set up for the Object List table to limit the security label columns displayed. If the Edit Attribute Values action is launched from the table, only the columns for security labels that are available are displayed in the window. If you plan to create a custom table view and share the view with your users, the view should be created and shared prior to making the system available to users to prevent unintended authorization to modify values.

• When implementing custom evaluator and translator classes, performance may be impacted as methods in the custom classes will be called frequently by Windchill. If you are setting up a call to an outside system, for example, you may consider caching the returned values to improve performance on subsequent method calls.

• If you are using custom security labels, PTC recommends adding validation to the user interface if users are able to enter values manually, such as by using the text field provided by default when custom security labels are configured. A custom translator class is recommended to validate the values to prevent unexpected values from being stored in the database, either if the user enters an invalid value in the user interface or if an invalid value is specified in an import file.

• Ensure that an administrator is able to modify a standard or custom security label value, in case it is mistakenly set by a user to a value that restricts the user access, and the user needs assistance correcting the value.