Workflow definition transfer
You can transfer a workflow definition or collection to the isolated region.
Before a workflow can run, an executable version of the workflow definition or collection must exist in the isolated region. Saving a workflow definition or collection in an object store or library saves the file but does not make it executable.
- In the administration console, start the Transfer Workflow wizard:
- In the domain navigation pane, select the object store.
- In the object store navigation pane, click and select a workflow definition.
- From the workflow definition tab, click Actions and select Transfer Workflow.
- Complete the wizard steps.
- In Process Designer
- A workflow author can directly transfer the workflow definition (by using Transfer Workflow from the Action menu) or workflow collection (by using Transfer Workflow Collection from the File menu) to the isolated region.
- When you launch the workflow definition (by using Launch Workflow from the Action menu) or main workflow (by using Launch Main Workflow from theFile menu or by selecting the Launch Main Workflow tool on the Process Designer toolbar), the Launch command transfers the workflow definition or collection and creates an instance of the workflow definition or collection.
Transfer to the isolated region

Each time a workflow definition or collection is transferred, a new workspace is created in the isolated region to point to the executable version of the workflow and to the latest revision of other previously transferred workflow definitions or collections. (In fact, each workspace actually contains two pointers to a workflow definition or collection--one to the author format and one to the runtime format of the workflow definition or collection.)
In the illustration at left, the size of the workspace increases as more workflow definitions are transferred. When there is a new revision of a workflow definition, such as Alpha in the illustration, the newer revision, Alpha_1, replaces the older one in the workspace list. This mechanism acts as a type of version control, making it possible to have multiple revisions of a workflow that can be run in an isolated region.
In a development environment, it is normal to have a large number of workspaces and to have the size of the workspaces increase fairly rapidly because workflow authors transfer and test workflow definitions many times before releasing them into the production environment. In this situation, it is possible to exceed the size limit of the workspace. Workflow system logs a warning message in the system event log when the BLOB size of a configuration object or a work item exceeds 95% of the maximum allowable size. If the workspace size limit is reached, a workflow transfer command results in a 'buffer overflow' error. To resolve this problem in a development environment, the workflow author can initialize the isolated region and clear out the workspaces.
In a production environment, there are usually fewer and smaller workspaces than in a development environment because only tested and stable workflow definitions are usually present in the production environment. Since it is generally inconvenient to initialize a production isolated region to clear out unused workspaces, some care should be taken to avoid large numbers of unnecessary transfers to the isolated region in a production system.
Not recommended

In the illustration at left, the workflow author creates essentially identical versions of the Alpha workflow definition by changing the name of the workflow definition and re-transferring. Note that this results in a rapid increase in the number of workspaces and the size of the workspace because each of these workflow definitions is considered unique.
As an alternative to this technique, use a data field in the workflow to update the Subject of the workflow at launch time as a way of identifying each running workflow.