Define Association Rules
You can create and modify association rules from the Association Rules table.
To access this table, navigate to the Utilities page under Site 
or Organizations 
. Select Business Rules. For more information, see Association Rules Table.
or Organizations . Select Business Rules. For more information, see Association Rules Table. | You can create rules 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 rule are preferred over site-level rules. |
Creating the Association Rules
1. From the Association Rules table, click the new association rule 
icon.
icon.2. Complete the following fields under Type Attributes:
Association Type | Select one of the following options: • Change Process—Configure which objects to link 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 change 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 baseline members. • Table Data—Configure the association between regulatory submission types and table data types. • Regulatory Submission Subject—Configure the association between regulatory submission types and objects that are the subjects of the regulatory submission. These include parts, places, and customer experience regulatory decisions. • Regulatory Submission Driver—Configure the association between regulatory submission types and objects that are the drivers of the regulatory submission. These include parts, documents, places, UDI Supersets, customer experience, and customer experience regulatory decisions. • UDI Subject—Configure the association between the UDI superset types and part types.
| ||
Role A Type | Select an object type to represent Role A in the link relationship. The Role A object is typically the parent object. However, either Role A or Role B can be the owning object or required object. Options include the following: • Flexible Change Item • CAPA Plan • CAPA Request • Change Notice • Change Request • Customer Experience • Nonconformance • Problem Report • Variance
| ||
Role B Type | Select an object type to represent Role B in the link relationship. • Flexible Change Item • CAPA Plan • CAPA Request • Change Notice • Change Request • Customer Experience • Nonconformance • Problem Report • Variance
|
3. Complete the following fields under Instance Attributes.
The options that are available for each field depend on the selections you make under the Type Attributes fields.
Cardinality | The cardinality determines the number of Role B objects that are allowed in relation to the Role A object. Select one of the following options: many:many 1:many or many:1 1:many many:1 1:1 For example, you define Role A as a problem report, and Role B as a change request: • 1:many—A problem report can be linked to multiple change requests. Each change request can only be linked to a single problem report. • 1:1—Each problem report can only be linked to a single change request. Each change request can only be linked to a single problem report. • many:1—Each problem report can only be linked to a single change request. However, a change request can be linked to multiple problem reports. • 1:many or many:1—The link is limited depending on which association is created first. For example, a problem report is linked to a single change request: ◦ You associate a second change request to the problem report. A 1:many cardinality is enforced. The problem report can be linked to multiple change requests, but the change request can only be linked to a single problem report. ◦ You associate a second problem report to the change request. A many:1 cardinality is enforced. The change request can be linked to multiple problem reports, but the problem report can only be linked to a single change request. | ||
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.
Select one of the following options: None Role A Role B For example, you define Role A as a problem report, and Role B as a change request. The owning role is: • Role A—If a user wants to create an association between a problem report and a change request, they must first have modify access to the problem report. Furthermore, once the association is created, the change request can only be deleted by users who have modify access to the problem report. • Role B—If a user wants to create an association between a problem report and a change request, they must first have modify access to the change request. Furthermore, once the association is created, the problem report can only be deleted by users who have modify access to the change request. | ||
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. Select one of the following options: None Role A Role B For example, you define Role A as a problem report, and Role B as a change request. The required role is: • Role A—When a user creates a new change request, they must add a problem report as an associated object. Otherwise, the user receives an error message. • Role B—When a user creates a new problem report, they must add a change request as an associated object. Otherwise, the user receives an error message. |
4. Click OK.
You can edit or delete rules from the Association Rules table.
Required Role Constraint
The Required Role is a constraint to create an association between the change objects. You must select the Required Role value to create the Role A Type or Role B Type change object.
For example, the following table explains the required role constraint and description for creating change objects:
Association Rules | Role A Type Change Object | Role B Type Change Object | Required Role | Description |
|---|---|---|---|---|
Rule 1 | Problem Report | Prototype Change Notice | None | The Required Role (None) is a constraint to create change object. You can create Role B type change object (Prototype Change Notice) without Role A type change object (Problem Report). Or You can create Role A type change object (Problem Report) without Role B type change object (Prototype Change Notice). |
Rule 2 | Problem Report | Production Change Request | Role A | The Required Role (Role A) is a constraint to create change object. You cannot create Role B type change object (Production Change Request) without Role A type change object (Problem Report). |
Rule 3 | Production Change Request | Production Change Notice | Role B | The Required Role (Role B) is a constraint to create change object. You cannot create Role A type change object (Production Change Request) without creating Role B type change object (Production Change Notice). |
The wt.change2.associationRuleEvaluateRequiredRole.enabled property controls the visibility of the Role A or Role B type change object during the creation of a change object. Based on the required role under the Association Rules, creating the change object violates the required role constraint of association rule.
If set to true, either the Role A type or Role B type change object that you want to create is not visible based on the required role under the Association Rules.
Consider the following scenario when creating the change object. If Role B is Required Role, then Role A type change object will not be visible. If Role A is Required Role, then Role B type change object will not be visible. As a result, you cannot create the change object at the initial step.
If set to false, either the Role A type or Role B type change object that you want to create is visible based on the required role under the Association Rules. However, at the final step of creating the change object, you will receive an error message stating that creating the change object violates the required role constraint of the association rule.
The default value is false. An administrator can set the property.