How to use SharePoint Designer 2013's Visual Designer to Move Workflows Between Sites

Hello all,image

My name is Sam Chung, and I’m a PM here at SharePoint Designer.  In this blog we’re going to talk about a great new scenario we’ve fully enabled now with the Import/Export feature found in the Visual Designer.


For many developers, there comes a special time in their lives when a strong need will arise, a need to spread their workflows. In particular, it will be the need to move their workflows between sites. This need can arise for many reasons, with the more common reason being the need to move a workflow between development, staging, and production environments. But whatever the reason may be, I’d like to use this article to help you guys out when trying to move your workflows from one site to another.

Before I begin though, please make sure to read over the following articles:

The first is a general overview of the Visual Designer:

You will need to read the above article to understand how the Visual Designer works.

The next is an article on how to package your lists and your workflows using our packaging feature:

You will need to understand the above article in order to understand how to package whatever lists your workflow may be referencing.

Creating your Workflow

Your workflow can be pretty much any workflow. There is no technical limitation in terms of what you can move. However, please take note of the following points if you want to avoid publishing and run-time issues:

1. Make sure that all objects that are being referenced in your workflow exist in the target site.

a. Read the packaging article to figure out how to package your lists

2. Make sure that all actions that are being used in your source site exist on the target site

a. If you have any custom actions which exist on your source site, you must make sure to bring those over to your target site before you bring over your workflow

3. Moving Project Workflows from a PWA site to a non-PWA site is not possible.

a. SPD will block this during import if it detects a Project workflow being imported into a non-PWA site.

b. We have a lot of extra data in a Project workflow and as such, these should only be moved from a PWA site to another PWA site

For this blog, I’m going to use a fairly simple workflow as an example. I will be enabling an Ideas list for an event scenario. The workflow I am going to create will be a simple workflow that will be used on an “Event Ideas” list. Users will enter in a new list item for every event idea that they have. Once they’ve filled in all of the required information, they will indicate that the item is ready for review. At that point, the workflow will kickoff and ask certain approvers to approve or reject the idea.

The list I’ll be using is this one:


You can see how this list has the following columns:

· Event Idea

o Single Line String

· Location

o Single Line String· Cost

o Currency

· Status

o Choice Field

And the workflow itself looks like this:


Here is what the workflow is doing:


· Log to history that we’re in the first stage

· Check to see if the Status column field is set to “Ready for Review”

o  If it’s not, wait until it is set to “Ready for Review”


· Log to history that we’re now assigning tasks to review the idea

· Update the status column to “Under Review”

· Assign tasks out


· If the idea was approved, we’ll come to this stage where we’ll log to the history that the idea was approved

· Set the Status column to “Accepted”


· If the idea was rejected, we’d come to this stage where we’ll log to the history that the idea was rejected

· Set the status column to “Rejected”

Exporting the Workflow

Now that we have our workflow, let’s go ahead and export this guy out. We do this by doing clicking on
the “Export to Visio” ribbon button.


NOTE: Pressing the Export button will automatically save your workflow first to the server and then start the export feature. The reason for this is because we need to ensure the exported workflow is in-sync with the server version at the time of export.

Pressing that button will bring up the following dialog:


Select where you’d like to save the file and press the “Save” button.

This will now have saved your Visio diagram to your selected location. If you so wish, you can open the diagram right away in Visio 2013.

Note: In this example, we exported the workflow from the Visual Designer, but it is possible to export your workflow from the following places:

· Text-Based Designer

· Workflow Settings Page

· Workflow Gallery

But in all of these examples, you must have the Visual Designer enabled. And in order for this to happen you must have Visio 2013 Professional installed on the same machine as SharePoint Designer 2013.

Importing In the Workflow

Now that you have exported your workflow, you can now open up another SharePoint 2013 site in SharePoint Designer 2013 and import in your workflow. Here are the steps you will take:

1. Connect SPD to a new site

2. Click on “Workflows” in the navigation pane


3. Press the bottom half of the “Import from Visio” ribbon button, and select the “Import Visio 2013 Diagram” option


4. This will bring up a regular Open File dialog. Go find your exported diagram and open it.


5. This will bring up the “Create Workflow” dialog

a. Give your workflow a name

b. Give it a description if you want

c. Notice how the Workflow Type is greyed out to “List Workflow”. This is because SPD has detected that the imported workflow is a list workflow. And as such, it has automatically selected the correct workflow type. If you were importing in a fresh new diagram from Visio (A workflow that has never been in SPD), this option would have been enabled.

d. Since this is a List Workflow, the option to select which list to associate the workflow to is enabled. Go ahead and select a list.  This option is only enabled for List Workflows. Ideally, you would have exported and imported in your List as well, in which case, you could just select the same list you were working on in the previous site.

e. Press OK


6. This will now bring up your workflow diagram, exactly as you saw it before.

a. All of your workflow logic has been retained

b. All of your action properties have been retained

c. All of your local variables have been retained

7. You can now go ahead and continue editing your workflow. But before you publish, make sure you read the next section.

Post Deployment Work Before Publishing

Once you’ve imported in your workflow from a different site, you cannot go ahead and try to publish it right away. Although this might work without any errors, your workflow will almost surely fail during run-time. Once you’ve imported in your workflow, make sure you do/check the next following steps:

1. Go to your workflow settings page, and update the Task List and History List

a. If you take a look at it now, you’ll see how it says “New Task List” and “New History List”. However, due to a late breaking change, when you publish your workflow, it will not make new Task and History lists. Which will cause your workflow to error out on runtime.


b. There should already be existing Task and History lists you can choose. Go ahead and choose those.

Note: If you really do want to create a new Task or History list, just click on a different list first, and then re-select the New Task List or New History List option. This will then bring up popups that will ask you if you really want to create a new list. And once you’ve confirmed that you want to create new lists, SPD will create these new lists right away.

2. Fix up your Lookups

a. If you did not bring over your lists with your VSDX file, you are most likely associating your workflow to a totally different list. As such, if you were referencing any list items or properties, you might need to fix those up.


b. You can get around this if you package your list from your original site and deploy it to the new site before you import in your workflow. To learn more about packaging your list, see this blog: Packaging List, Site, and Reusable Workflow and How to Deploy the Package

3. Check for any custom actions in your Workflow that don’t exist in your new site

a. If you do have custom actions in your workflow, make sure you deploy those actions onto your new site before you import in this workflow.

4. For Project Workflows: Make sure you’ve brought over your Stages, Phases, PDPs, and Custom Fields before you import in your workflow.

a. Project Workflows require that all of the previous Project Objects have been brought over from the old site to the new site. Take a look at the Project Blogs to find out more about how to move your Project Objects.

Once you have taken care of these issues, you should have no problem publishing and running your workflow on your new site!

Hope this article was of use to you. Feel free to leave comments below.