I needed to write a customized approval workflow. I know I could use InfoPath to create custom approval task forms, and I saw many posts showing how this is done. But if I could use the SharePoint Approval Workflow task forms, I could save a lot of development time and deployment effort.
This post focuses on how I was able to use the out of the box InfoPath approval approve/reject task forms forms in my custom Visual Studio SharePoint workflow.If you’re looking for a general how-to post on creating SharePoint workflows with Visual Studio, this is not the post for you. I would instead point you to Serge Luca’s excellent 20-part series on
creating SharePoint workflows with Visual Studio.
Creating the task
Here’s the skinny on what you need to do in order to use the default Microsoft Office SharePoint Server 2007 (MOSS) approve/reject InfoPath form in a custom Visual Studio workflow.
1. Create a SharePoint workflow project
There are many ways to do this, so I won’t go into details here. My personal favorite way is by using the
WSP Builder Visual Studio workflow template project. Just make sure that your workflow class inherits from
System.Workflow.Activities.SequentialWorkflowActivity or from
System.Workflow.Activities.StateMachineWorkflowActivity.
2. Set the TaskListContentTypeId attribute
Edit the
elements.xml file in your workflow feature definition. Set the
TaskListContentTypeId attribute value to use the MOSS workflow task content type id:
<Elements>
<Workflow
Name="MyWorkflow"
Description="This is my custom workflow."
…
TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
>
…
</Workflow>
…
</Elements>3. Add the Task_FormURN and ExtendedStatusColumnValues elements
Continue to edit the elements.xml file in your workflow feature definition. Add the following MetaData element under the Workflow element:
<Elements>
<Workflow …>
<MetaData>
<Task0_FormURN>urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID;</Task0_FormURN>
<Task1_FormURN>urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID;</Task1_FormURN>
<Task2_FormURN>urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID;</Task2_FormURN>
<ExtendedStatusColumnValues>
<StatusColumnValue>$Resources:ReviewFeedback_CanceledStatus</StatusColumnValue>
<StatusColumnValue>$Resources:ReviewFeedback_ApprovedStatus</StatusColumnValue>
<StatusColumnValue>$Resources:ReviewFeedback_RejectedStatus</StatusColumnValue>
</ExtendedStatusColumnValues>
</MetaData>
…
</Workflow>
…
</Elements>4. Add a CreateTask activity to your workflow
Add a
CreateTask activity to your workflow. Make sure to set the
TaskType property on the
TaskProperties of the CreateTask activity to
1. This will tell the workflow runtime to create the task using the Form Urn corresponding to the inner text in the
Task1_FormURN element. The CreateTask activity’s
MethodInvoking event is a good place to set the property.
private void createTask1_MethodInvoking(object sender, EventArgs e)
{
//initialize task infrastructure data
this.createTask1_TaskId1 = Guid.NewGuid();
this.createTask1_TaskProperties1 = new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
this.createTask1_TaskProperties1.TaskType = 1;
//set task remaining properties
//...
}
Processing a workflow task
Now that you’ve created a workflow task that uses the default approval form, you will want to your workflow to do something useful when a user approves or rejects the task. Here is how to detect when a user approves or rejects the workflow task.
5. Detect task change with OnTaskChanged
This is fairly straight forward: add an
OnTaskChanged activity to your workflow. Set the task ID and correlation token to correspond to the ones used when creating the task in the previous section. See Serge Luca’s SharePoint workflow series for details.
6. Task approved or rejected
Here’s the
interesting part. Whether a user approves, rejects, reassigns, or requests a change in the task form, the task is always marked as Complete. The actual value that corresponds to what the user selected is stored in the
TaskStatus in the
ExtendedProperties collection of the
SPWorkflowTaskProperties class. The following is a table that correlates the user’s approval action to the value of the TaskStatus extended property:
| User Action | TaskStatus Value |
| Approve | “#” |
| Reject | “@” |
| Cancel | [no change] |
Here’s a sample helper method that checks whether a particular workflow task was approved:
public static bool IsTaskApproved(SPWorkflowTaskProperties TaskProperties)
{
return TaskProperties.ExtendedProperties["TaskStatus"] != null
&& TaskProperties.ExtendedProperties["TaskStatus"] as string == "#";
}
Anything else?
That’s it. There is surprisingly little work involved in using the default MOSS approvals forms in your own custom SharePoint Visual Studio workflows, once you know what to look for that is. I’d like to wrap us this post with the benefits to this approach and a few things you should keep in mind when working with the default workflow forms.
Some benefits to this approach
Here are just some of the benefits you get when you reuse the existing MOSS approval task forms rather than creating your own customs InfoPath task forms:
- No InfoPath forms development
- No InfoPath forms deployment
- Out of the box user interface for:
- Approve
- Reject
- Cancel
- Reassign Task
- Request a change
- Instructions to approver
- Capture approver comments
- Out of the box multi-language user interface with appropriate MOSS language packs. Notice the references to “$Resources:”.
A few things you should know
- Any action in default task forms except Cancel marks the task “Complete”. Your workflow must then create a new task with the desired action from the completed task. For example: If a user re-assigns the task to a new user, the task for the user is marked complete. Your workflow must create a new task and assign it to the new user.
- The MOSS task forms derive most of their data from fields in the ExtendedProperties of the task, not the main task properties.
