Using Workflow Changes in Workflows
Workflow changes let you make changes at run time to a running instance of a workflow. These changes might be motivated by omissions at design time, changes to properties and bindings of activities, or a need for business logic that enhances and more completely models business processes. Workflow changes are not intended for situations in which you want to make wholesale changes, resulting in a workflow that differs significantly from original design principles. In a case such as this, you should design a new workflow instead of making changes to a running instance.
Workflow changes apply to a single instance of a workflow. They do not support type-based changes that replicate to all running and future instances of a given workflow type.
You can use workflow changes to do the following:
Change workflow structure, for example, add or remove an activity.
Change flow control.
Some examples of common workflow changes include the following:
Change a RuleSet used by a PolicyActivity activity.
Update RuleCondition definitions to change the behavior of branching activities, such as ConditionedActivityGroup and IfElseActivity.
Add a new custom activity or an InvokeWorkflowActivity activity if you have to add a new business process to your workflow after you deploy and start running it.
Author changes declaratively using workflow markup from outside the workflow, taking updated markup as a parameter to make the change.
Add a new EventDrivenActivity activity to respond to a new event, such as an additional approval step.
Applying a workflow change to a running workflow can occur in two different entry points: in the workflow code file, and outside the workflow, such as the workflow host. For more information about applying workflow changes, see How to: Apply Workflow Changes to Workflows.
Restrictions on Workflow Changes
The following are a few restrictions on workflow changes imposed by Windows Workflow Foundation that you must be aware of:
Activities can be added or removed from a workflow instance, but properties on an existing activity cannot be changed unless those properties are declarative rule conditions or rule sets.
Custom composite activity types that incorporate child activities as part of its definition cannot have its child activities dynamically added or removed. This is because custom composite activities like this are "black box" activities and cannot be fundamentally modified during runtime.
An activity that is not in the Initialized or Closed states cannot be removed dynamically during run time.
A workflow developer can restrict the use of workflow changes through an ActivityCondition attached to the root activity of the workflow, which is used by the workflow runtime to determine whether or not any workflow changes are allowed for a specific workflow instance.
Custom composite activities can validate proposed changes, such as the addition or removal of child activities. This enables activity developers to determine whether any proposed workflow changes conflict with the intended functionality of their activity. This functionality is provided through a custom ActivityValidator, where developers can override the ValidateActivityChange method and add their custom workflow changes validation logic.
See Also
Concepts
How to: Apply Workflow Changes to Workflows
Other Resources
Developing Windows Workflow Foundation Activities
Developing Workflows