SharePoint Caveat – BeforeProperties in SharePoint workflow

I had to develop an application to track the status of delivery of an order whose details would be stored in a list. To accomplish this I had to choose either an event receiver or a workflow. I chose workflows since workflows would give me a better development environment with visual representation of the flow of process using which I can do the changes so easily which is not possible with event receivers.

Of course I chose to go ahead with Visual Studio workflow rather than SharePoint designer workflow due to the recursive process involved in the requirement.

I started my development and was so happy with the way it was progressing until I faced with a hurdle which led me to stop developing the workflow and instead start with an event receiver from scratch. I was really disappointed with that.

The requirement was to compare the values of a certain field before and after the list item has been updated. This can be achieved by creating 2 workflow properties to store the after properties and before properties of the list item.

The problem was when I found that BeforeProperties was always null in the ItemUpdated event activity and only the AfterProperties had values in it. I wondered why it is null always. When I tried the same workflow for a document library instead, I found that both BeforeProperties and AfterProperties to be holding values and were not null.

After googling I found that workflows for lists have the same limitation as that of event receivers for lists. And that is finding null value in the BeforeProperties for a list item in an ItemUpdated event receiver in a list. This limitation is present in both event receiver and workflow when attached to a SharePoint list. But you can overcome this limitation in an event receiver by replacing Item Updated event receiver with an Item Updating event receiver. In an Item updating event receiver you can find values in the BeforeProperties of the item that is getting updated. You can more about it over here. But in a workflow attached to a list there is no work around which means workflow is not going to be of much use for a list in this case.


Visual Studio Workflow development caveats

I really enjoyed developing custom workflows for SharePoint in Visual Studio 2010. By saying that I enjoyed, I meant that I enjoyed solving some head aching exceptions in completing the workflow development.

So, I have decided to write about the caveats to be taken care in developing Visual Studio Workflow.

NOTE: I’m not going to explain how to create a Visual Studio workflow as it is out of scope of this post.

I have created a Sequential workflow in which when an user is uploading a document to a document library a task with custom content type that I developed would get created for another user to approve the document. Once the user approves it, the workflow status column text would read as “Approved” which is our custom status column value.

Below are the exceptions that I faced after deploying the workflow:

1. When the user uploaded the document to the document library, I expected the workflow to create a task with the custom task content type that I developed but instead the workflow status message read “Error Occurred” as shown below.

And also I found the below error in the workflow status page which says “An error has occurred in ReviewWF”:

I could not find an explicit exception message describing the reason for the error either in the Workflow history list or in the Event viewer. So I decided look at ULS logs where I found the below error stating:

“The content type of a workflow task must be derived from the Workflow Task content type.”

After seeing the above error I got to know that when I created my custom task content type in Visual Studio I chose the base content type to be Task as shown below:

This is not the correct way to create a custom task content type for workflow. The base content type should be Workflow Task Content type which is not listed in the above list (I’m wondering why it is not listed).

In order to associate our content type to workflow task content type we need to change the ID property of our content type. Initially when I chose Task as the base content type the ID property for the content got created as “0x010800e0b69596ca8143379c6484a932beaeea” in which 0x010800 in the beginning represents the ID of the base content type: Task, which has to be replaced by 0x01080100 which is the ID of the Workflow task content type. Finally the new content type will look like: 0x01080100e0b69596ca8143379c6484a932beaeea.

 Now after I deployed the workflow, custom task got created successfully.

2.   I had listed my custom workflow status column values in the Element.XML within ExtendedStatusColumnValues tag of my workflow as shown below:


When the approver approved the document, the value in the status column got changed to “Approved”:

Now, I wanted the value to be “Finished” instead of “Approved”. So I changed the value accordingly in the element.xml and re-deployed it. But when the approver approved the document the status column value of the workflow was still reading “Approved” as shown below:


This was giving me headache for a long time until I discovered that removing the workflow from the library and adding it again had it working. Now I get the correct value in the workflow status column as shown below:


To remove the workflow you need to go to the workflow settings of the library and select Remove a workflow, select the radio button below the Remove column for the corresponding workflow and click Ok as shown below:


I’m yet to figure out why is it so. Removing the workflow also deleted the workflow history of all the previously added items leaving no record of its past which is a huge limitation.