Change Association Rules Table
Change association rules allow you to define rules for object-to-object associations. For more information, see Change Association Rule Administration.
Site and organization administrators can create, modify, and view change association rules using the Change Association Rules table.
To access this table, navigate to the Utilities page under Site 
or Organizations 
. Select Business Rules.
or Organizations . Select Business Rules. | The Change Association Rules table is available at the organization level when the wt.associationRules.enableOrganizationRules property is set to true. By default, this property is set to false. If you define rules at the organization level, those rules are preferred over site-level rules. |
Actions
Actions are available from the table toolbar and from the right-click actions menu in the table rows.
 Delete | Delete the rule. | ||
 New Change Association Rule | Create a new association rule. For more information, see Define Change Association Rules. | ||
 Export | Export the selected rules. | ||
 Import | Import one or more rules from an existing ZIP or JAR file. | ||
 Edit | Edit the selected rule. When you select this action, the rule is automatically checked out. When the Edit Change Association Rule opens, you can make your changes and select one of two actions: • OK—Your changes are saved and the rule is automatically checked in. • Cancel—You perform an Undo Checkout operation and your changes are discarded.
| ||
 Undo Checkout | You can use the Undo Checkout action if the Edit Change Association Rule window closes unexpectedly. |
Table Columns
For information on creating custom table views, see Creating and Editing New Table Views.
General Status | A status indicator appears when an object is checked out to you or another user. For more information, see Object Status. | ||
Number | A system-generated number for the rule. | ||
Association Type | The process type or a reference type: • Change Process—Configure which objects can be linked as part of the same change process. This also dictates the applicable object types available to add to the Associated Process Objects table. • Change Reference—Configure which objects can be linked as references, but are not necessarily included in the same change process. This also dictates the applicable object types available to add to the Associated Reference Objects table. • Change Implementation Plan—Configure the association between a change notice and its tasks. • Impact—Configure the association between objects that impact each other in order to execute specific actions on those objects. For example, a change task impacting variant baseline members. | ||
Enabled | When this checkbox is selected, the rule is enabled and available for use. | ||
Role A Type | The object type that represents Role A in the link relationship. The Role A object is typically the parent object. However, depending on the association type, either the Role A or Role B object can be the owning object or required object. | ||
Role B Type | The object type that represents Role B in the link relationship. In some situations, both Role A and Role B might be assigned to the same object type. For example, you create a rule in which both Role A and Role B are assigned to the change request object type. Role assignment is determined as follows: • Owning role—If the owning role is set and you only have the required permissions for one object in the relationship, then the owning role is assigned to the object. For example, the owning role is set to Role B. You modify a change request named “Request 1” and add a pre-existing change request (“Request 2”) to the Associated Changes table. You have modify permission to Request 1, but not to Request 2. As a result, Request 1 is assigned the value of the owning role (Role B). • Context—If the owning role is not set, or if you have the same permissions for both objects, then roles are assigned using the context of the action you are performing. The object on which you are performing the primary action is considered the Role A object. For example, you modify a change request named “Request 1” and add a pre-existing change request (“Request 2”) to the Associated Changes table. In this situation, Request 1 is the Role A object. | ||
Context | Site or Organization
| ||
Cardinality | The cardinality determines the number of Role B objects that are allowed in relation to the Role A object. | ||
Owning Role | The owning role allows you to restrict who can create, delete, or modify associations. To create a link, users must have modify access to the owning role object. Furthermore, the non-owning role object can only be deleted if the user has modify access to the owning role object.
| ||
Required Role | The required role identifies associations between objects that are required. If the user attempts to create an object without adding the required role, an error message appears. | ||
Link Type | The link type matches the selected Association Type. • Change Process Link • Change Reference Link • Implemented By • Impact Link |
For more information, including examples of how these properties are used, see Define Change Association Rules.