I noticed in several occasions that whenever I customize the OOB approval workflow or modify its task form, the Request Change and Reassignment (Reassign Task) stop working. Before we are going into the workaround, I want to outline how the OOB Approval workflow interacts with its Initiation Form. The task page (WrkTaskIP.aspx) contains an XmlFormView control. The page’s code behind will parse the task form’s infopath xml data into a Hashtable that will be passed into the Approval workflow (OfficeTask) workflow through this SPWorkflow.AlterTask method. Then the workflow will access the hashtable during its process via SPWorkflowTaskProperties.ExtendedProperties, and it relies on the correct combination of keys-values of the hashtable.
The most important key in the Hastable is the TaskStatus, with value equals to the submit data connection of the associated button as shown in the picture. So for example the Request Change button is clicked the task status will be set as ChangeRequest.
if(Request Change clicked) hash["TaskStatus"] = "ChangeRequest"
Another interesting fact is that the hash table’s key will be changed to the field’s Guid of the Task list where the workflow task resides if it has a field with internal name or static name equal to the key. So in this case if the associated task list’s Status field has static name equals to TaskStatus, the hashtable key will be replaced with the Guid of the Status field.
So if we have a custom form with custom submit connection and a custom workflow, our workflow need to handle extedendProperties["TaskStatus"] = “our submit connection’s name” and extendendProperties[SPBuiltInFieldId.TaskStatus] =”our submit connection’s name”.
With this knowledge we can troubleshoot some of the OOB Approval workflow issues:
- The Change Request and Reassign Task are not executed at all. Symptom: You click the Request Change or Reassign Task button with Request Change From/Reassign Task To field empty (means reassign the task to the originator). Nothing happen to the workflow and it just stays at current approval process. The Request From and Reassign Task To field are represented by FieldName_RequestTo element and FieldName_DelegateTo element respectively. And they have infopath Person xml in their inner xml. In the unmodified task form the inner xml is literaly empty string when the fields are empty, but whenever we modified the task form the inner xml is not empty but an empty Person element. Somehow the OOB approval workflow fails whenever the value is an empty Person xml. To workaround this we need to set the default values of this two fields to empty.
- The Change Request and Reassign Task are executed but instead of creating a new task it change the current status to ChangeRequest or ReassignTask. This is something to do with the TaskStatus ExtendedProperties as I mentioned in a previous paragraph that the TaskStatus key might be replaced with a GUID if in the task list’s Status field has static name equals to TaskStatus. To fix this one, the Status field’s static name needs to be changed. The best practise is changed it to the same as the internal name. How do we know/change the static name of the field? The answer is Powershell, open the SharePoint administrator and check the static name of the Status field, if it is equals to TaskStatus, change it. Below is short powershell code.
#$list is the workflow task list $field = $list.fields["Status"] #if static name = TaskStatus $field.staticname = $field.internalname $field.update()
- When a user has assigned a Change Request task, the Request field on the task form is empty even though there was a comment. The request field is associated with the Description field (Body is its internal name) of the task list. The field is a Note field (Multiple lines of text) and the infopath form expects it as a plain text. Somehow when we modify the OOB task form, the Description field is provisioned as a Rich Text field. We can change this setting to Plain Text from the list settings as below.