Workflow change propagation

Earlier, workflow definition could not be updated if the workflow was in use. For instance, if the workflow had collaboration area that is associated with it, and items were checked out to the collaboration area. Changes were made in Version 6.5.0 to enable you to change a workflow while it is in use.

A workflow is "in use" if there is any collaboration area defined that references the workflow, whether or not that collaboration area is empty. It is recommended that workflows that are in use NOT be updated. However, such workflows may be updated if the following guidelines are followed:

Environment export and import: The workflow definition can be changed in the source environment and exported. The definition can then be imported to the target environment in which the corresponding workflow is in use. When complex workflow changes need to be applied, it is recommended to use the "Environment export and import" approach because it allows changes in a consistent manner within short update intervals. It also should be done while having a full online database backup and having stopped all workflow activity.
Script operations: In the Product Master environment, script operations to update a workflow can be completed while the workflow is in use.
Java™ APIs: The Java API methods can be used to update a workflow while it is in use.

Important: Deleting a workflow is still not allowed while it is in use or associated with a collaboration area.

While you are updating the workflow the following guidelines must be followed:

Make sure that no operation is running with any collaboration area associated with the workflow that you want to update. These operations include activities like checking out items or importing items into a step. The update fails in such a case.
After the workflow update operation is started, make sure that no new events are posted to the collaboration areas associated with that specific workflow. This can again include activities like checking out or importing items to a step, or working with items already present in the step. These operations fail while the update operation is still going on. Those operations can be done after the update is completed.

You can complete the following operations on a workflow to update it while it is still in use:

Add a step to the workflow. The associated collaboration areas are refreshed to get the new step.
Delete a step from the workflow. If there are any items that are checked out to in any related collaboration area which is in this step at the time, they are moved to the FIXIT step of the workflow. Also the events pending for this step are deleted. If this step is in a nested workflow, the entries in the corresponding steps of the containing workflows are moved to the FIXIT step of the containing workflow.
Edit the other attributes of a workflow. If other attributes of a workflow are changed, such as, name, description, the changes reflect in the environment.
Edit the properties of a step in workflow. The properties or attributes of any step can also be changed and the workflow can be updated. Here is a list of some valid scenarios:
- The deadline or timeout for a step can be changed.
- The Reserve to edit flag can be cleared. In this case, all the entries in the step for which this change is made are unreserved if they are in reserved state.
- The performer for a step can be deleted. If a user is no longer a performer for the step, due to change in performers that are defined for the step, then all the entries in the step that is reserved by that user are unreserved.

If any of the updates are made to a nested workflow, the change is propagated to all the containing workflows, and the collaboration areas that are associated with them.

The target environment can have items that are checked out to collaboration areas related to the workflow. The changes that are made to the code must allow the workflow in the target environment to be updated and the items must be adjusted according to the status of the new workflow.

Workflow aspects can be changed in the source environment and propagated to the target environment, including the name of workflow or workflow step. If the name is changed, the target environment considers this workflow or step as a new one, and does not update the existing workflow or step. You must take care of this aspect if you change the name of a workflow or a step.

After the export is complete, the workflow description is available in the WORKFLOW.xml file within the exported compressed file.

Sample:

<WORKFLOW>
	<Name>NewProductIntroductionV2</Name>
	<Action>CREATE_OR_UPDATE</Action>
	<Desc>Process for introducing new products.</Desc>
	<ACG isDefault="true"/>
	<ContainerType>CATALOG</ContainerType>
	<GUIDocStorePath>/workflow/gui/NewProductIntroductionV2.html</GUIDocStorePath>
</WORKFLOW>

If you change the name, you must manually provide an extra tag in this exported file after the <Name> tag as follows: <OldName>NewProductIntroductionV1</OldName>.

You must follow the same approach if the name of a step is changed:

<Step>
	<StepName>TechnicalEnrichmentStep_new</StepName>
	<StepOldName>TechnicalEnrichmentStep</StepOldName>
	<StepType>MODIFY</StepType>
	<StepDesc></StepDesc>
</Step>