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!
I am trying to use these Else branches without success. I am trying to do something like...... If Variable equals Approved Go to Stage 2 Else If Variable equals Rejected Go to End of Workflow I don't have the option to add a 'Go to'. Can you please help?
Found the reason why. I wasn't putting it in the 'Transition to Stage' section. The 'Go to' branch now appears. However, the workflow doesn't go to the correct stages. Any suggestions appreciated. Thanks
I had this epxerience, too.
When deleting to "Go to..:" Action within the "Transition section",
then you should be able to FIRST place an "IF THEN ELSE", and in there, add the "Go to..." Actions.
It would be nice though, if instead of just reverting my selected values (which are tedious to set OVER AND OVER) SPD MIGHT give an error message that describes the problem. However, I know that useful error messages are not Microsoft's style.
i built a form in infopath 2013, and i added two radio buttons , one for approved and one for not approved, so i built the workflow ,
the" if approved "stages all work fine till the end of the workflow (if approved, it actually moves to the next stage and all the stages , but if its not approved (else if statement), it dosent send any mail, it just stops.
The else if statements just dont work
i don't know what i'm doing wrong,