Recently we had a request form one of our clients to have a conditional approval workflow activated on different value of a field in the document library on SharePoint 2010. To be specific, they want different types of project documents to be approved by different approvers or groups. Although this seems a simple one, SharePoint OOTB approval workflow doesn’t really provide an easy way to do that.
After some research, we figured that two ways could be used to achieve this, either use a custom content type with a taxonomy site column, or create more content types in the document library. Now that’s what we learned something from.
1. Custom Content Type with Taxonomy Field:
We want different approvers to approve based on different values of the taxonomy field, let’s say, if it’s ProjectA Document, let Michael to approve, if it’s ProjectB Document, Nicole will get notified of the task.
(Just a note that we compare taxonomy value in workflows like: If we want to compare the values, need to use value and GUID pair like: TaxonomyColumn = ProjectA|12356789-abcd-xxxx-xxxx-xxxxxxxxxxxx, which is metadata value + GUID of the term)
As most cases, for the interests of enterprise search for documents in this library, we go to term store and create terms there, and then site column, site content type. Afterwards, we make the content type available to the document library. Now everything is good, we can see the taxonomy, and we can create workflows based on the new content type. However, when it actually comes to work, a weird thing appears: when we upload a document and specify the new content type with all fields populated, the workflow doesn’t kick off, or it assigns a task to wrong approvers, or even the workflow status field might show Completed!
It’s not a SharePoint bug, but a SharePoint behaviour in Document Library. When you want to upload a document for approval, if you click Upload button, it’s already uploaded to the library as the default content type, with no chance allowing users to populate the properties. And it’s exactly when the workflow get kicked off. So chances are, even if you specify the value of taxonomy field in the properties page and save, the right workflow won’t start working.
Solution: We usually set workflow to run when a new item is created, so what we need is pause the workflow for 1+ minutes.
2. Multiple Custom Content Types Associated with Document Library:
We create a workflow for each of those content types, and when user uploads a document and they choose a content type, the associated workflow runs.
Just a heads-up of this solution, as it might get end users confused, especially for new comers to SharePoint, and it’s not Enterprise Search friendly. But the beauty in it is, it will allow users to use OOTB SharePoint Approval Workflow creation interface to specify different approvers every time without resorting to SharePoint Designer.
The success of this solution is all counting on Default Content Type of the document library.
For instance, this time we have Data and Documentation and some other content types, and for each content type there is a workflow. If someone has specified the default content type of the document library to be Data let’s say, then when a user upload a document, before he/she changes the content type in the properties setting pop-up page, the workflow for the default content type will be working already. That’s why you will question your eyes like why on earth this workflow got kicked off.
Solution: Always set the default content type to be OOTB Document (assuming there is no linked workflow with Document content type). Of course, also don’t remove it from the document library.
After all, you might want to hide all the status columns for all the workflows, otherwise it would be quite confusing (below is also what we got from testing stage with wrong workflow running when document was uploaded):