Category Archives: Workflow

How to conditionally start different workflows yet retain a single status field

I have a situation where a single item in a list can have any one of literally dozens of possible workflows running against it.  Creating views against this is next to impossible as you have to account for all the various status fields that can be involved.  Even the simplest request becomes a nightmare.

Let me explain by example: let’s say a particular list item can have three possible workflows: Approve Lease, Approve Purchase, and Approve Loan.  These flows need to go to completely different groups of people in order to get approved so I naturally create three instances of the Approval workflow with the proper people assigned to each.

A user then enters a new request into the system using my custom WebPart.  In that request is a dropdown with three options: “Buy, Borrow, Lease”.  Based on this value, my WebPart determines the proper workflow and starts it.  Sort of – more on this in a bit.

With no customization, I would have to create a view for each workflow: Rejected Purchases, Rejected Loans, Rejected Leases and would have to create three more for In Process as well as three more for Approved.  Nine views and we haven’t even gotten started yet!  As I mentioned, in my real-world problem, an item can have dozens of possible workflows, so this list of views becomes overwhelming quickly.  In addition, it is unnecessarily complex to determine the answer to a simple request : display all rejected items.  In the above example, I would have to create yet another view and filter it where each workflow status field is Rejected.

What I actually end up doing is much simpler.  I have a special purpose workflow created based on the Approval Template called “Current Workflow”.  The WebPart grabs the proper workflow based on the dropdown value, copies the EventData (this is the stuff that differs between workflows based on the same template) and uses it when starting the “Current Workflow”.  Thus, all workflow activity limits its updates to the one status field for Current Workflow.

The net result is that now I can initiate the proper workflow and all of my views can use the status in the “Current Workflow” field to make their determination for approval / rejected.  Going back to the example, I’ve cut the number of views from the initial 10 to 3.  I can add any number of additional workflows and I will still only have three views needed.