This article is on the best practice recommended approach for migrating workflow definitions and workflow context between ServiceNow instances.
Migrating Workflow Definitions.
1. Before migrating workflow definitions, you should migrate user and group records or ensure that corresponding users and groups have been created on the target instance. These are required because there may be references to users and groups in the workflow activities.
2. Create a new project from the Precision Bridge Workflow Definitions template. By default only published workflows are migrated.
3. Execute the project to migrate the workflow definition and all related workflow objects to the target instance. You can set the execution variable to either migrate a specific workflow or migrate all published workflow. If you want to migrate a single workflow, you must provide the Workflow Name.
When Workflow Definitions are migrated, they always created as new and checked-out. A manual step is required to publish the migrated workflow. If the migration is run more than once the workflow is NOT updated and the record is skipped. This is to avoid updating workflows that may have been published and could be in use.
To update a workflow, first delete the definition from the target instance then re-run the workflow definition migration as above.
Migrating Contextual Workflow
Contextual workflow is workflow that is related to a transaction record such as incidents, problems, changes and requests. To migrate contextual workflow between ServiceNow instances, follow these steps:
1. Migrate the workflow definitions for the corresponding workflow context records using the method outlined above.
2. Create a new project from the Precision Bridge template for the transaction records that include contextual workflow. The following templates are available which include contextual workflow mappings: Incident (including SLA workflow context), Incident State Model Conversion, Problems, Change Requests, Service Requests (including Requested Items workflow context)
3. Review the source filter on the parent record (Incident/Problem/Change Request etc) to ensure that it includes the records that you want to migrate.
4. Execute the project to migrate the transaction records and all related contextual workflow to the target instance. Note that the project variables Migrate Workflow, Migrate Request Workflow and Migrate Requested Item Workflow must be set to TRUE for the corresponding contextual workflow to be migrated.
All migrated contextual workflow versions are created as un-published and not checked-out. They are only used to support the continuation of the workflow for the migrated transaction and cannot be edited directly.
Following migration, the contextual workflow will continue from the same point that it would on the source instance for the same transaction. e.g. if on the source transaction, the workflow is currently waiting for an approval activity, then the same approval activity will be assigned on the target workflow. Once the approval is granted, the workflow will continue on to the next activity.
If the workflow context migration is run more than once then the corresponding workflow context records are skipped and not updated. This is to avoid corrupting the target workflow which is currently in progress.
If you need to re-create the workflow context records on the target instance, you should first delete the workflow context records from the target instance, then re-run the migration.
Comments
0 comments
Please sign in to leave a comment.