We just needed to implement ASPX forms for a SharePoint workflow. Knowing that this was not very well-documented when SharePoint 2007 came out, I was prepared for some extensive searching to find what I was looking for ...except, after 2 1/2 years since that last SharePoint release, there's still no proper documentation available on this yet. At least I couldn't find it. It also doesn't help to repeatedly hear from MS executives, like Chris Capossela, that "about 20,000" pages of documentation have been added in 2008" ...go figure.

 

Alright, back to the usual rescue: the SharePoint community!

 

There is actually one example for ASPX forms that shipped with the WSS 3 SDK. It's called ASPXCollectFeedback. I assume it's there just for me to make my point: Serge Luca details nicely all the problems that have to be fixed in this project before it can be run. And then it also doesn't really include a comprehensive overview of the involved conventions (nicer word for hard-wired mechanisms that come with the SharePoint implementation of the Workflow host).

So, what is there to cover? The workflow implementation in SharePoint builds on a few concepts. To start with, a workflow can be associated with either a list, content type, or a content type in a specific list. Also, by convention, every time a workflow is associated, one list needs to be linked that will hold the workflow tasks, and another list that will hold the workflow history. This is implemented in a standard page which is called the “Attachment form”.

 

  Attachment Form

The form that follows directly after the Attachment form is the “Association form”, in which the default values for the workflow should be set. The Association form is the first (out of a total of five types of forms) that needs to be implemented. This involves retrieving the data that was entered by the user in the Attachment form, presenting the form to the user and then saving the user input once again.

 

 
Association Form

 

When a user then afterwards selects a workflow to be run on a specific list item, the SharePoint workflow implementation will bring up the "Instantiation form" (sometimes also called Initiation form). It usually resembles the Association form, but can, of course, be entirely different. Also, it's important to know here that workflows can be started automatically (e.g. on upload of a document), in which case the Initiation form will not be displayed.

 

 
Instantiation Form

 

Then, you would typically have different "Task forms" for the various tasks that are part of your workflow. This is where one usually realizes that all of this is going to be a bit more tricky than you'd hope for, as there is no aspx page to be specified for the task edit form, as is the case with the previous two forms.
 
Let's look at how the standard InfoPath-based workflow solution in SharePoint does it ...here too, aspx pages (NOT InfoPath forms!) are specified in the workflow.xml:
 
       AssociationUrl="_layouts/CstWrkflIP.aspx"
       InstantiationUrl="_layouts/IniWrkflIP.aspx"
       ModificationUrl="_layouts/ModWrkflIP.aspx"
 
The SharePoint workflow implementation always uses aspx pages to host the "controls" that were created by building an InfoPath form. (It is a common misunderstanding that the entire InfoPath forms are being used).
 
The first two forms (Association and Instantiation) are easy: we can just define our own aspx pages and reference them here. However, I didn't make a mistake by not listing the aspx form for editing a task above. There is none. One needs to use the Metadata section in the workflow.xml to specify the TaskID_FormURN Elements for the different tasks. When using InfoPath controls the tasks and their corresponding forms are to be linked manually using the TaskType field of each task, which needs to match the enumerator that the FormURN has (e.g. Task0_Form ...another SharePoint convention). However, this only works out of the box with the InfoPath forms implementation.
 
Now, in order to use ASPX forms instead of InfoPath, one either has to use a separate custom content type for each task that needs specific forms (as custom content types allow to specify individual "new, display, and edit" forms). Such a task in the workflow then has to be created using the “CreateTaskWithContentType” activity (referencing the Guid of the respective custom content type). Or, one would have to create separate ascx user controls to be hosted by the aspx page of the standard task, similar to what the implementation for InfoPath controls does. As you might have guessed it, either way comes with its own challenges and work-load.
 

 

 

There’s (only) two potential caveats with his sample: 1) you have to deploy his solution on a subsite (and NOT the rootweb/sitecollection), as otherwise you’ll run into some security issues, and 2) you need to add an “if (!IsPostBack)” to the code in the “Page_Load” method that reads the Association form data into the Instantiation form. Both problems are mentioned and detailed in the comments of their respective posts on Robert’s blog.
 
My recommendation however is to use the new WSS3Workflow solution on Codeplex, that implements the ascx user control approach. I've tested it and it worked well. It's still a bit short on the documentation side of things, but simply open up the Sample project that gets installed and you will get the idea. There are also 3 videos available by now that give some basic information on this solution.
 
Funnily enough though, both in Robert’s sample as well as in the WSS3Workflow sample, only the Extended Properties collection is used to store the task data, even though a custom content type is implemented. It should be noted that the fields (== task list columns) of the custom content type can easily be accessed (e.g. using the Guid of the FieldRefs in the custom content type).
 
Are we done yet? Not quite. I still owe you some info on the other two workflow forms that are part of the SharePoint workflow implementation.
 
The "Modification form" is used in conjunction with the “EnableWorkflowModification” activity: while the workflow is within the scope of the “EventHandlingScope” activity that includes the EnableWorkflowModification activity the link to the Modification form is visible in the Workflow Status page. For this to work, the Guid used in the Modification_GUID_FormURN element must match the modificationID of the EnableWorkflowModification activity. Typically, one would use the Modification form  to modify the workflow, e.g. by adding additional instructions or adding another Approver.
 

Workflow Status Form
 

Modification Form 

That leaves us with the last form to look at: the “Bulk Edit Task form”. Obviously, if you’re an approver and you routinely get a lot of documents to approve then it might make sense to shortcut that process and display and edit all tasks that are of the same kind (workflow & association) on the same page, instead of bringing up the Workflow Status form for each task individually. In order to do so, the specific task needs to be identified explicitly as “TaskN_IsBulkActionable” in the Metadata section of the workflow.xml (whereas N is again the TaskType enumerator.

 

 

It needs to be noted that the WSS3Workflow solution differs a bit, as much as conventions are concerned. E.g. the Menu command for bulk editing tasks can then be found in the “Actions” menu of the list that contains the items for which the workflow has been instantiated, whereas otherwise the InfoPath-based bulk edit mechanism is available in the Actions menu of the Task list.

 

Kudos to Robert Shelton, Chris Predeek and Wouter van Vugt!