Move Copy a Designer Reusable Workflow to a new site farm
SharePoint Designer workflows can be exported to solution files and then imported in a different Site Collection or a different SharePoint Farm. Now they can even be opened in Visual Studio 2010, although it's not a reversible process and once opened in Visual Studio they can't be changed using SharePoint Designer anymore.
Our primary goal in this article is to learn how to move SharePoint Designer 2010 workflows across farms and while this feature can be useful in many scenarios, I strongly encourage you as a developer to try to build your workflows in Visual Studio, this is the proper way to implement, distribute and maintain any workflow.
In previous versions the main issue was that these workflows could not be moved across environments. It was not possible to design a workflow in a development platform, then move it to a test environment for testing and finally once accepted deploy it to production, workflows had to be created directly at production and tested from there.
Here we are creating a new SharePoint Designer workflow, it has to be a reusable workflow because only those can be then saved as templates. For this demo I just created a workflow that logged a string in the workflow history. Once we have finished with the workflow we save it and we click on the "Save as Template" button on the ribbon bar.
This will generate our Solution .wsp file and save it in the "Site Assets" document library on the current site.
After this the next step is to download a copy of the Solution file and upload it to the other SharePoint Farm where we want to move the workflow to. We navigate to the Solutions gallery and upload the .wsp file, finally we have to activate the solution.
Uploading it to the solutions gallery on the web application present on the new farm –
Once activated, a new feature will appear on the Site Features of all sites in the current Site Collection, we navigate to the Site where we want to use the new workflow and activate that feature.
This feature deploys the workflow to the workflows list and after activating it we would expect to have the new workflow available in the Site Collection.
If we navigate to the Workflows list at the Site Settings page, we should find our workflow here.
If for some reasons the workflow isn’t listed inside this list, suggest you to open the site in designer and publish the workflow on the new site. This will publish the workflow again in the Site Collection and after we do that it will appear on the workflows list and we will be able to run it and associate it to SharePoint Lists.
I hope this helps you in moving SharePoint workflows across farms without any issues.
More Information:
Understanding Association Columns - https://blogs.msdn.com/b/sharepointdesigner/archive/2011/05/02/association-columns.aspx
Comments
- Anonymous
November 20, 2013
How can it be achieved using either by STSADM / Powershell. - Anonymous
December 04, 2013
Once I follow all the steps and open the workflow with SharePoint designer in the new environment, all the actions in the workflow that referenced fields in the Current Task are broken. They look like [%ID11462.ReturnValue%]. If I try to manually fix them, the popup for adding or changing a lookup has an option in the first drop down to select the current task but there are no fields that get populated in the second drop down. - Anonymous
December 05, 2013
The comment has been removed - Anonymous
February 06, 2014
Hello,I followed all the steps and was able to import the workflow from Site A to Site B within the same site collection. But anothe site in the same site collection, Site C has all the links broken and they look like [%ID11462.ReturnValue%] just as the previous commentator said. I checked the Site Content Type upto the parent Item/Task and it is not missing any of the columns. Dod anyone find a resolution to the [%ID11462.ReturnValue%] error and how to fix it?Thanks. - Anonymous
April 18, 2014
I also had the same problem as the poster from 4 Dec 2013 so I decided to post a fix for anyone else who runs across this. In my case I had an approval task process in my workflow that I'd renamed from "Approval" to something more descriptive. Upon exporting the workflow and examining the WSP in Visual Studio I noticed SharePoint had exported the task content type for that approval process with the old "Approval" name and left the "<Fields />" tag blank in the XML. The blank "Fields" tag caused the Approval content type to be created incorrectly when importing the workflow into a new site and was also the reason for the broken field references for "Current Task" in my workflow.The reason for this turned out to be the name of the XSN (InfoPath) file SharePoint generates for the approval task form. For some reason it uses THAT as the content type name (instead of reading the name from the actual content type) when exporting the workflow. By manually fixing the XSN name in the "All Files/Workflows" folder in SharePoint Designer and updating my workflow's "xoml.wfconfig.xml" file to reference the new name I was able to get the workflow to export correctly and the content type (and field references) were fixed when I imported it into a new site. NOTE: After editing any workflow files manually in SPD you must close and reopen SPD for the changes to take effect.