My mate Yaohan keeps telling me to “man up” and learn how to use Visual Studio and Windows Workflow Foundation to build SharePoint workflows. I just can’t bring myself to do it – It would be such a major transition for me that the rest of my work would suffer.
Something I’ve been noticing recently (while using my girly-girl SharePoint Designer workflows) is how the logging to workflow history behaves a bit strangely. When doing SPD workflow, the history log entries don’t get written until the end of the step they’re created in… so if your workflow crashes out near the end of say step 6, the last log entry you’ll see is the last one written on step 5. Sometimes this makes it hard to troubleshoot where the issue actually is.
Serial Actions do not complete in order
Also running actions in serial does not mean things complete in order. As an example: just because within a single workflow step “Action 1” creates an activity list item and assigns the item id to a variable, doesn’t mean that “Task 2” (which writes the variable to another list item) will be writing any useful information (When it tries to read the variable, it reads an empty string and replaces it with ???? in some cases). This is because the reading of a variable happens a lot faster than the creating of an activity – and it looks like SharePoint is still creating the list item when it hands back control to the workflow. The only way to guarantee it (as far as I can tell) is to read the variable on a subsequent step.
Commit & Proceed
Putting these 2 issues together, it seems that there must be some kind of "Commit and proceed" phase at the end of each step. Having discovered these two anomalies, I’ve started to change the way I build workflows now to leverage this. I now try and spread my workflow out between multiple steps, with each step containing a decision (or conditional test) and a single action or activity for each “branch” of the decision (Think "Baby Steps").
Custom Workflow Logging
Also, I now use a custom list to log workflow progress (and configure the behavior of your workflows) for more complex workflows, or ones that need a permanent audit trail – this provides me with a permanent log (vs the history log which “cleans up” events after 60 days) and allows me to change the workflow behaviour without modifying the workflow. For example, if you build a workflow that emails a report to some execs, set a “debug” flag in a list or read the recipients from a list you’ve created. That way you can do all your testing with your own email address and set it up for Executive receipt once you have finalised it and ironed out the issues. Paul Galvin discusses the 60-day Workflow history log in more detail here, including recommending the creation of a Custom list to create a workflow log. Some other people have strong feelings on the thinking behind this “auto-cleanup” feature too, so much so that Microsoft have released instructions on how to disable the cleanup job.