I worked on a support case recently and wanted to share the learning to the community. The issue was that when we create a SharePoint 2013 Workflow in SharePoint Designer 2013, add a few actions and values in it and save the workflow, part of the values wouldn’t persist in the workflow XOML file. You can confirm it by closing and reopening the workflow in SharePoint Designer 2013. Well, it’s not actually any workflow you design that depicts this behavior, but only workflows that is built using a particular incorrect logic.
To give you a better understanding, here are the steps to reproduce the problem.
1. Create a document library in a SharePoint 2013 site and name it “Docs1”.
2. Add two currency columns (actually, any column would do to reproduce this behavior) named “Currency1” and “Currency2”.
3. Open this site in SharePoint Designer 2013.
4. Create a SharePoint 2013 Workflow associated to a list (List Workflow with platform SharePoint 2013 Workflow). The list in this case would be “Docs1” the document library.
5. Use the below logic in the default stage of the workflow in the designer.
6. Save and close the workflow. Open it again and you’ll see that the values are persisted.
7. Now create another stage with the following logic.
8. Now, save the workflow again and close it.
9. Reopen the workflow and now you’ll see the values you provided in the conditions are lost in Stage 2.
That’s the repro of the problem. If you look at the logic of the individual stages, you’ll find it doesn’t make sense to actually have a Stage 2. Because both the ‘if’ and ‘else’ branch in Stage 1 of the workflow ends the workflow.
As you know, the new SharePoint 2013 Workflow works declaratively (XOML). The size of the XOML file has a say on how efficiently the workflow runs. In the case of the above workflow, SharePoint parses through the logic of the workflow as well and determines ‘Stage 2’ is actually not needed at all. So, it simply omits the values in it when saving the workflow but leaves ‘Stage 2’ design in the designer (which, presumably is stored in the XOML file just as a reference as not with the actual values). And thus the so called “problem”. Well, this isn’t actually a problem, but it’s the way SharePoint tried to optimize things.
We resolved this by making the ‘if-else’ logic more meaningful as shown below.
After this change, the entire workflow design was persisted as expected.
Though this is something small, I was taken by surprise when this was reported as a problem and was quite impressed by the way SharePoint and SPD 2013 works together to try to ensure it executes actions (and activities in VS Workflows) in an optimized way!