Reference Relationships
For some references, you can create a functional dependency between the package and the referenced entity. For example, you can specify that a request is a predecessor to the package. This means the package cannot continue until the request is closed.
-
Predecessor Relationships. Predecessor relationships dictate that action is not allowed on one entity until the referenced entity closes. For example, a package cannot complete any workflow action until the referenced task is closed (Completed, Bypassed, or Cancelled). The package status is Pending Task. After the task closes, the package can be acted upon after more. This does not stop other request fields from being edited.
-
Successor Relationships. Successor relationships dictate that action is not allowed on the referenced entity until the entity closes. For example, a referenced task cannot change status until the original package is closed. The task status is Pending Request. When the package closes, the task can again be changed. This does not prevent other task fields from being edited.
Table 2-1 lists the references, their definitions, and possible dependency relationships.
Predecessor Relationships
Predecessor relationships dictate that action cannot be performed on one entity until the referenced entity closes. For example, a package cannot complete any workflow action until the referenced task is closed (Completed, Bypassed, or Cancelled). The package status is Pending Task. After the referenced task closes, the package can be acted on again. This does not prevent the editing of other request fields.
Successor Relationships
Successor relationships dictate that action is not allowed on a referenced entity until the entity closes. For example, a referenced task cannot change its status until the original package is closed. The task status is Pending Request. After the package closes, the task can be acted on. This does not stop other task fields from being edited.