Data Retention between Task Recasts
When a Task Recast happens, there may be some Steps that have acquired data, and some Steps that have not acquired data yet.
Following a Task Recast, previously acquired data, Step Validations and Non-Applicability statuses continue to be associated with the Task, exactly as they were prior to the Recast, unless structural changes were made to the Steps.
Important
No data loss occurs during Task Recasts or when Recasts are 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 Template that has been used for the Recast. This renders it visible or invisible to the user accordingly.
Any Step data dissociated from a Task due to a Recast can be associated with it again by canceling the Recast.
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 new Template version.
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. They will still be available with the Task Timeline.
This is described in detail below.
Signoff Action Attributes | Description |
|---|---|
Signoff Action Identifier | If the new Signoff action's identifier has not changed from the previous Template version, then the old Signoff action holds good after the Task Recast. If the new Signoff action's identifier has changed from the previous Template version, the Signoff action performed before the Task Recast is dissociated. The Signoff action must be performed again after the Task Recast. |
Signoff Action Role | If the new Signoff action can be performed using the same Roles as the previous Template version, the Signoff action will continue to be associated with the Task based on the new version. For example, consider the below scenario: In Template v1.0.0, Role A can Signoff a Step. In Template v1.0.1, Role A or Role B can Signoff the same Step. The Task was recast from v1.0.0 to v1.0.1. If the Step was signed off before the Recast, the signatures and stamps will be associated with the Task after the Recast too. There will be no need for another Signoff action after the Recast. However, if in Template v1.0.1, Role A and Role B are required to Signoff the Step, then the Signoff done before the Recast will be dissociated. The Signoff action needs to be performed again in keeping with v1.0.1 of the Template. |
All the data collected by each version is saved internally. As a result, whenever a Template Recast is canceled, the data collected by the Task prior to the Template Recast is associated with it again.
A Template can have multiple versions. A Task Recast can be done only to a newer version of the Template. However, a Mass Recast can be done to any version of the Template.
In the example below, the user executing a Task running on v1.0.1 can perform a Task Recast to the later versions, v1.0.2 or v1.0.3, but not to an earlier version, v1.0.0.
However the Template Author can perform a Mass Recast on all Tasks and Recast them to any of the four versions, even an earlier one. So, a Task running on v1.0.1 can be Recast to v1.0.0 through a Mass Recast.
 |