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. |
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.
| ||
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
|
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. |
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). |