Data Management Capabilities > Managing Change > Change Management Administration > Change Management Preferences
Change Management Preferences
Preference settings determine a variety of change object behavior.
The visibility of preferences is determined by how you access the Preference Management utility:
• Some preferences are set at the user level.
To view and modify your individual user preferences, select Quick Links > My Settings > Preferences.
• Some preferences are set at context, organization, or site level by an administrator.
From the Navigator, select Utilities under a specific context, organization, or site. Click Preference Management under the Business Administration utility category.
If a preference is visible but cannot be edited, then this preference has been locked at a higher level.
To change a preference, select Set Preference from the right-click actions menu of the preference you want to change. For more information, see Preference Management and Setting a Preference.
* 
In the tables below, “Visibility” indicates the lowest level at which the preference can be set:
• “User” means that an individual user, context administrator, organization administrator, or site administrator can view or set the preference.
• “Context” means the preference can be set for a site, organization, product, library, project, or program.
• “Organization” means that organization and site administrators can view or set the preference.
• “Site” means that only site administrators can view or set the preference.
However, your local administrators might change the default preference visibility.
Change Management
The Change Management preference group determines the behavior for change objects.
Affected End Items Display
Visibility
Context
Default
Yes
Description
Determines the visibility of the Affected End Items table.
If set to Yes, the Select Affected End Items step appears when creating or editing problem reports, variances, and change requests:
* 
If set to No, this preference is ignored for problem reports, variances, and change requests that already have existing affected end items, or for changes that exist in project contexts.
Associated Issues Display
Visibility
Context
Default
No
Description
Determines the visibility of the Associated Issues and Variances table.
If set to Yes, the Associated Issues and Variances table appears when creating change tasks.
* 
If set to No, this preference is ignored for change tasks that have existing associated issues or variances.
Automatic Change Notice Creation
Visibility
Organization
Default
Yes
Description
Automatically create a change notice from the task page of a change request.
CAD Model On Same Change Notice
Visibility
Context
Default
Yes
Description
This preference affects mass change operations when working with parts built from CAD documents.
When set to Yes, any parts built from CAD must have the correct associated CAD model on the corresponding change notice when performing mass change operations.
Change Baseline Report Display
Visibility
Organization
Default
No
Description
If set to Yes, the Change Baseline Report is included in the list of reports that is available from the product structure reports.
Change Implementation State Definition
Visibility
Context
Default
Implementation
Description
The life cycle state that determines when a change notice is in the implementation phase.
The value specified marks the change notice workflow under the implementing phase. The value also starts the change sequence plan; a change sequence plan is started only when the change notice is in the specified state. Only one life cycle state can be specified as the implementing state.
Change Information Propagation
Visibility
Context
Default
Yes
Description
The preference determines whether the Propagate information checkbox is available when creating a creating a change request, problem report, variance, or change notice from an existing change object. For example, when selecting Actions > New > New Variance from the information page of a change request:
The information that is propagated includes attributes, affected objects, and attachments.
• Yes—The checkbox appears, but is not selected by default.
• Selected—The checkbox appears and is selected by default.
• No—The checkbox does not appear.
Change Modification Tracking
Visibility
Organization
Default
No
Description
This preference controls whether revisions are allowed for change objects. Revision information is available in the Revision History table for the change object.
The use of the feature requires proper process design. Life cycle templates must define revise transitions and users must be granted revise permission at the appropriate life cycle states. For more information, see Phase Transitions and Setting Permissions.
Change Notice with Embedded Change Task
Visibility
Organization
Default
No
Description
When set to Yes, simplified change notices are enabled.
This means that if there is only one change task associated with the change notice, the Implementation Plan table is not displayed on the change notice information page.
Instead, the Implementation Plan tab displays information about the change task, the Affected Objects table, and the Resulting Objects table.
Change Notice without Change Request
Visibility
Context
Default
No
Description
Determines whether users can create a change notice without first creating a change request:
• Yes—Users can create change notices at any time.
• No—Users can only create a change notice from an existing change request.
* 
• This preference only applies when Windchill is in Legacy change association mode.
• If set to Mixed or Flexible mode, you can use change association rules to determine whether a change request is required. For more information, see Change Association Rule Administration and Flexible Change Link Conversion.
Change Request to Change Notice Cardinality
Visibility
Organization
Default
No
Description
• Yes—Users can associate multiple change requests to multiple change notices.
• No—This is the equivalent to a “1:many or many:1” link. The association is limited depending on which association is created first. For example, you link a change request to a change notice. If you link a second change request to the change notice, then a 1:many cardinality is enforced. The change notice can be linked to multiple requests, but the change request can only be linked to a single change notice.
Change Request to Problem Report Cardinality
Visibility
Organization
Default
No
Description
• Yes—Users can associate multiple change requests to multiple problem reports.
• No—This is the equivalent to a “1:many or many:1” link. The association is limited depending on which association is created first. For example, you link a problem report to a change request. If you link a second change request to the problem report, then a 1:many cardinality is enforced. The problem report can be linked to multiple requests, but the change request can only be linked to a single problem report.
Collector
Visibility
User
Description
These are a set of preferences that determine the default collection rules.
You can set default rules when collecting objects for the following tables:
• Affected Objects
• Resulting Objects
Copy Superseded Parts to Resulting Data Table
Visibility
Organization
Default
No
Description
When parts are superseded, they can be set to an alternate state to show that they have been superseded.
• Yes—The superseded parts are copied to the Resulting Objects table so that their state can be changed when the change notice is released.
• No—The superseded parts are not copied to the Resulting Objects table and no changes are made to their state.
* 
If you enable this preference, you must also configure the corresponding life cycle template with the appropriate transition configured to automatically or manually pick the target state.
Expose Organization for Change Management Objects
Visibility
Organization
Default
No
Description
Expose the organization for all change objects.
Inline Editing of Dispositions
Visibility
User
Default
Yes
Solution
Windchill Risk and Reliability
Description
• Yes—You can perform inline edits for disposition values.
• No—Inline editing is disabled. However, this improves performance if you are attempting to make mass changes.
For more information on working with dispositions, see The Windchill Nonconformance Process.
Localized Create New Change Notice Task Name
Visibility
Organization
Default
Create New Change Notice
Description
Change the “Create New Change Notice” workflow task name that is generated in the change request workflow process.
When you provide a localized name as the value in this preference, you also update the label for the checkbox that appears allowing you to automatically create a change notice from the change request task page.
* 
The name you provide must match the name of the corresponding workflow activity in the change request workflow.
Lock Annotations
Visibility
Organization
Default
Yes
Description
Set this preference to Yes to automatically lock annotations when a change object is manually moved to a terminal state. Annotations are not locked if the state changes through a workflow process or when imported.
When set to No, annotations associated to a change object are not locked.
Multiple Release Targets
Visibility
Context
Default
Yes
Description
Determine whether users can select the release target for resulting objects:
• Yes—The Release Target column of the Resulting Objects table displays a drop-down menu.
• No—The Release Target column displays either the default value as read-only or the persisted target.
Optional Assignee and Reviewer States
Visibility
Context
Default
<not set>
Description
You can use this preference to defer the assignment of the assignee and reviewer to a later life cycle state.
When you select a life cycle state, this means that the change task assignee and reviewer are optional for selected life cycle states.
By default, no states are selected. As a result, all life cycle states require assignee and reviewer assignments.
Prevalidation Compare Icon
Visibility
Site
Default
No
Description
This preference determines the type of validation that should be performed on objects in the Resulting Objects table of a change task. The validation determines the visibility and availability of the Compare action.
• Yes—Perform a full validation on objects in the Resulting Objects table. The Compare action is available for all objects. However, this can affect system performance when change tasks have a large number of resulting objects.
• No—Perform a partial validation on objects in the Resulting Objects table. However, the Compare action icon might appear for objects where the action is not applicable.
Problem Reports in Projects
Visibility
Context
Default
No
Solution
Windchill ProjectLink
Description
• Yes—Users can create problem reports for objects shared to a project.
• No—Users cannot create problem reports for shared objects. However, existing problem reports remain visible.
Sequenced Plan Execution Order
Visibility
Context
Default
No
Solution
Windchill ProjectLink
Description
A sequenced implementation plan allows the change notice author to determine which change tasks should be completed before other change tasks can be started.
• Yes—When creating or editing a change notice, you can optionally specify the order in which change tasks should be implemented.
• No—Change notices do not support change task sequences.
When enabled, the Sequence column appears in the Implementation Plan table:
* 
This preference only applies when Windchill ProjectLink is installed.
If you are using sequenced implementation plans and manually perform a Set State action, the following occurs:
• If the state is set to a resolved or canceled state, change tasks are marked as completed in the implementation plan.
• If the state is set to a state other than resolved or canceled, then all executing change tasks are permitted to complete, but the processing of the sequenced implementation plan is suspended.
Set Resolution Date
Visibility
Organization
Default
Yes
Description
Set this preference to Yes to automatically set the resolution date to the current time when a change object is manually moved to a terminal state. The resolution date is not set if the state changes through a workflow process or when imported. If the resolution date is already set, the change object is not updated with a new resolution date.
Unincorporated Change Creation
Visibility
Organization
Default
No
Solution
Windchill Aerospace & Defense
Description
• Yes—Allow users to create unincorporated changes.
• No—Users cannot create unincorporated changes. However, existing unincorporated changes remain visible.
For more information, see About Unincorporated Changes.
Variance Effectivity
Visibility
Context
Default
No
Description
If set to Yes, effectivity statements can be specified for the affected objects of a variance.
Variance Owner Role Name
Visibility
Context
Default
VARIANCE AUTHOR
Description
The role name of the variance owner.
If you change the value of this preference, you must also modify the variance life cycle and workflow to include the corresponding role.
Variances in Projects
Visibility
Context
Default
No
Solution
Windchill ProjectLink
Description
• Yes—Users can create variances for objects shared to a project.
• No—Users cannot create variances for shared objects. However, existing variances remain visible.
Create and Edit
The following preferences are available from the preference manager under the Create and Edit preference group.
Change Notice Create Default Type
Visibility
Context
Default
WCTYPE|wt.change2.WTChangeOrder2
Description
The default type used when creating a new change notice:
• To specify the wt.change2.WTChangeOrder2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeOrder2 (or one of its subclasses)
• To specify a change notice subtype, enter the following:
WCTYPE|wt.change2.WTChangeOrder2|com.ptc.<ChangeNotice>
• To indicate that the user must select a change notice type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
Change Request Create Default Type
Visibility
Context
Default
WCTYPE|wt.change2.WTChangeRequest2
Description
The default type used when creating a new change request:
• To specify the wt.change2.WTChangeRequest2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeRequest2 (or one of its subclasses)
• To specify a change request subtype, enter the following:
WCTYPE|wt.change2.WTChangeRequest2|com.ptc.<ChangeRequest>
• To indicate that the user must select a change request type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
Change Task Create Default Type
Visibility
Context
Default
WCTYPE|wt.change2.WTChangeActivity2
Description
The default type used when creating a new change task:
• To specify the wt.change2.WTChangeActivity2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeActivity2 (or one of its subclasses)
• To specify a change task subtype, enter the following:
WCTYPE|wt.change2.WTChangeActivity2|com.ptc.<ChangeTask>
• To indicate that the user must select a change task type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
Problem Report Create Default Type
Visibility
Context
Default
WCTYPE|wt.change2.WTChangeIssue
Description
The default type used when creating a new problem report:
• To specify the wt.change2.WTChangeIssue class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeIssue (or one of its subclasses)
• To specify a problem report subtype, enter the following:
WCTYPE|wt.change2.WTChangeIssue|com.ptc.<ProblemReport>
• To indicate that the user must select a problem report type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
Promotion Request Create Default Type
Visibility
Context
Default
WCTYPE|wt.maturity.PromotionNotice
Description
The default type used when creating a new promotion request:
• To specify the wt.maturity.PromotionNotice class (or one of its subclasses), enter the following:
WCTYPE|wt.maturity.PromotionNotice (or one of its subclasses)
• To specify a promotion request subtype, enter the following:
WCTYPE|wt.maturity.PromotionNotice|com.ptc.<PromotionRequest>
• To indicate that the user must select a promotion request type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
Variance Create Default Type
Visibility
Context
Default
WCTYPE|wt.change2.WTVariance|com.ptc.Deviation
Description
The default type used when creating a new variance:
• To specify the wt.maturity.WTVariance class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTVariance (or one of its subclasses)
• To specify a variance subtype, enter the following:
WCTYPE|wt.change2.WTVariance|com.ptc.<Variance>
• To indicate that the user must select a variance type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
External Associated Change References
Visibility
Context
Default
No
Description
This preference controls the addition of external objects to the Associated Reference Objects table.
Set the preference to Yes to create association of external change objects as reference objects. This configuration will enable the associating external change objects as reference objects feature.
Set the preference to No to disable the association of external change objects as reference objects.
Promotion Process
For information on the Promotion Process preference group, see Promotion Process Preferences.
Action Control for the Change Management Process
These are action control rules for the change management process. The following preferences are available from the preference manager under the Change Management Process Action Control preference group of the Change Management category.
Add Resulting Objects in Change Process
Visibility
Context
Default
Disable
Description
Enables the addition of resulting objects by search, or paste, or collect within a change context.
Set the preference to one of the following based on the required use of the Add Resulting Objects action:
• Disable—No restrictions for using the action within a change context.
• Any State in Change Context—Use in any state of change task within a change context.
• Implementation State in Change Context—Use in the implementation states of change task within a change context.
One-Off Version in Change Process
Visibility
Context
Default
Disable
Description
Enables the New One-Off Version action within a change context.
Set the preference to one of the following based on the required use of the New One-Off Version action:
• Disable—No restrictions for using the action within or outside a change context.
• Any State in Change Context—Use in any state of change task within a change context. The action cannot be used outside a change context.
• Implementation State in Change Context—Use in the implementation states of change task within a change context. The action cannot be used outside a change context.
Revise in Change Process
Visibility
Context
Default
Disable
Description
Enables the Revise action within a change context.
Set the preference to one of the following based on the required use of the Revise action:
• Disable—No restrictions for using the action within or outside a change context.
• Any State in Change Context—Use in any state of change task within a change context. The action cannot be used outside a change context.
• Implementation State in Change Context—Use in the implementation states of change task within a change context. The action cannot be used outside a change context.
Save As in Change Process
Visibility
Context
Default
Any State in Change Context
Description
Enables the Save As action within a change context.
Set the preference to one of the following based on the required use of the Save As action:
• Any State in Change Context—Use in any state of change task within a change context.
• Implementation State in Change Context—Use in the implementation states of change task within a change context.
Supersede in Change Process
Visibility
Context
Default
Disable
Description
Enables the Supersede action within a change context.
Set the preference to one of the following based on the required use of the Supersede action:
• Disable—No restrictions for using the action within or outside a change context.
• Any State in Change Context—Use in any state of change task within a change context. The action cannot be used outside a change context.
• Implementation State in Change Context—Use in the implementation states of change task within a change context. The action cannot be used outside a change context.



Was this helpful?