The canned workflows are powerful enough as is, but what happens if you really need to use them, but are in a situation that is just a little beyond their ability? There are ways to augment them slightly without having to re-create the whole workflow from scratch. Below is just one example.
This overall situation is pretty unique, but parts of it should be familiar to anyone who has done very much with the canned workflows. Hopefully this may provide another option for those of you beating your heads against similar issues.
Here's my scenario:
The main problem: A single list item can be subject to dozens of different workflows, which are all variations on the canned Approval flow but with different lists of approvers. Reports need to be generated so that a single report will show all items that are in a given state regardless of which flow it is in. Views like this are almost impossible out of the box with this many possible workflows.
The second problem: The current status needs to be visible in lists. However, the text of the status needed by the client is different than that defined in the workflow.
The third problem: The same workflow needs to run multiple times on the same item, but will result in a different status upon completion. The reason is that there is often a gap of weeks or months between the completion o the first workflow (feasibility) and that of the second (manufacture). During this time, things may have changed that make the product no longer feasible, so it has to go through the same people again to make sure that it can still be done. If so, the completed status becomes "Authorized".
The solutions
At first glance, it looks like you could take the hardline approach and create dozens, if not hundreds, of custom views, each tailored to the workflow needed. While this is doable, it doesn't address the second and third problems. It also sets up a maintenance nightmare.
The first problem was solved by the fact that all workflows in my situation are started by my WebPart rather than using the Automatic or Manual options. When the WebPart starts a workflow, the code determines the prope workflow to launch based on form data. It then copies that workflow's EventData and starts a single workflow using that data. (See my other post about the specifics of this)
The second problem proved much more difficult to conquer, but this solution manages to not only take case of the second one, but the third problem as well
EventHandlers to the rescue!
The solution was to create an EventHandler and attach it to the ItemAdded event of the list that the workflows put their history into. In my case, all history goes into a single list so that part was simplified.
Create the handler
A basic EventHandler is one of the simplest things to create. I've attached the code for my handler at the bottom of this post that illustrates getting the workflow status and updating the proper Item
http://msdn2.microsoft.com/en-us/library/ms437502.aspx
http://msdn2.microsoft.com/en-us/library/ms453149.aspx
Binding the Handler
In order for the handler to be called, it has to be registered in Sharepoint in some way. There are actually two ways to do this, but I found this to be easiest:
http://www.sharepointblogs.com/ssa/archive/2006/11/09/15899.aspx
Please note that if you do use this method to bind your handler, it only needs to be run once. There is no need to rerun it after you rebuild the EventHandler.
The other way is listed in the second link above and involves creating it as a feature. This just seemed like overkill for such a simple thing.
Wave Magic Wand
Determining the state of the workflow actually requires checking two places. The first place is the InternalState property of the workflow to determine if it running or errored out but it will not tell you if the item was Approved or Rejected, only that the workflow completed. That's a good start, but how do I find out Approved/Rejected?
Fear not! With a little searching, you can get hold of the Workflow which has a handy Xml property that holds all sorts of juicy nuggets of information. The one of interest here is the Status1 attribute as that is the keeper of the desired status. A Status1 of 17 is Rejected, 16 is Approved. (I'm sure that there are constants or an enum somewhere that maps to this, but I was unable to find it)
With this tidbit of Information, I can now immediately update my single Status field with the text that the customer needs to see. With this field now populated according to the proper workflow, I can create one set of views that all key off of the one single field. Nice and easy.
What's that you say? Why not just look for the status in the field associated with the workflow in the ListItem? This is a fine question indeed and one to which the only proper answer is 8. The only value that is ever in that field is 8, regardless of Approve/Rejected status. I'm assuming that 8 means Workflow Completed which, while informative and accurate, is of almost no use whatsoever.
The code that is attached demonstrates how to get to the actual status.
