Data Retention between Task Reworks
When a Task Rework happens, there may be some Steps that have acquired data, and some Steps that have not acquired data yet.
Following a Task Rework, previously acquired data, Step Validations and Non-Applicability statuses continue to be associated with the Task, exactly as they were prior to the Rework, unless significant structural changes were made to the Steps.
Important
No data loss occurs during a Task Rework or when a Rework is canceled. All data acquired on the Task is saved internally with the Task timeline.
The acquired data is associated with or dissociated from the Task based on the version of the Rework that has been used or canceled. This renders it visible or invisible to the user accordingly.
Any Step data dissociated from a Task due to a Rework can be associated with it again by canceling the Rework.
If the Steps that had acquired data were modified significantly, then the data acquired by those Steps are dissociated from the Task and a new version of the Step is created based on the changes introduced by the Rework.
The following are considered significant structural changes.
Changes to Steps | Description | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Incompatible Step Type | If data from the old Step Type can be associated with the new Step Type, the Step Type is compatible. If not, it is incompatible. The table below describes the compatibility of a Step Type following a Task Recast.
| ||||||||||||||||||||||
Change in Step Properties | If more than one of the following Step properties have changed, it is considered a significant structural change.
|
Steps Enabled For Signoff:
On Steps Enabled for Signoff, if there are no significant changes in the Signoff action attributes, the signatures and stamps will continue to be associated with the Task based on the new version.
If there are significant changes however, the signatures and stamps will be dissociated from the Task.
This is described in detail below.
Signoff Action Attributes | Description |
|---|---|
Signoff Action Identifier | If the new Signoff action's identifier has not changed due to the Rework, then the old Signoff action holds good after the Task Rework. If the new Signoff action's identifier has changed as a result of the Rework, the Signoff action performed before the Task Rework is dissociated. The Signoff action must be performed again after the Task Rework. |
Signoff Action Role | If the new Signoff action can be performed using the same Roles after the Task Rework, the Signoff action will continue to be associated with the Task based on the Rework. For example, consider the below scenario: In a Task, Role A can Signoff a Step before the Rework. After the Rework, Role A or Role B can Signoff the same Step. If the Step was signed off before the Rework, the signatures and stamps will be associated with the Task after the Rework too. There will be no need for another Signoff action after the Rework. However, if after the Rework, Role A and Role B are required to Signoff the Step, then the Signoff done before the Rework will be dissociated. The Signoff action needs to be performed again after the Rework. |
All the data collected by each version of the Task is saved internally. As a result, whenever a Task Rework is canceled, the data collected by the Task prior to the Template Rework is associated with it again.