Creating Multi-Stage Custom Workflows with SharePoint Designer 2007

Before you begin

Below is an example of a workflow that could be used to manage the SharePoint site provisioning process for businesses that may wish to control the creation of sub-sites. In many cases there are valid business reasons for preventing the adhoc creation of subsites by end users.

Keep in mind, the framework used to create this workflow process could practically be used for any business process requiring any number of stages.

In order to recreate this exercise you will need the following:

• SharePoint Server 2007
  
• SharePoint Designer 2007
  

Business Value

Traditionally large monolithic server applications (such as CRM type applications) have provided certain degrees of workflow automation. The problem however with this "one size fits all" approach, is that in many cases businesses have unique ways of handling similar processes. When the need araises to make rather simple changes to a large monolithic application it can become very costly - both in terms of time and dollars.

In very basic terms SharePoint gives businesses a flexible and extensible set of Web based tools for automating practically any process. Keep in mind however, that SharePoint has many rough edges and is still in the early stages of its evolution.

Considerations

• Nested Branching - do the limitation of SharePoint Designer 2007 being able to only support one level of branching, workflow logic in some cases must written in a suboptimal fashion (as illustrated in this example exercise).
  
• Potential for Orphaned Records – do to the limitation of SharePoint Server to enforce referential integrity at the database layer, without additional application constraints child workflow work items could become orphaned.
  
• Comparison Operators – SharePoint Designer 2007 limits the ability to compare an integer datatype (as used in an item ID column with a double datatype (as defined in a numeric column). The workaround for this issue is to modify the associated workflow XOML code (which is shown in this example exercise) in a text editor.
  
• Terminating the Primary Workflow – secondary workflows are unable to terminate primary workflows. This limitation may allow for rejected requests to keep their associated primary workflows active indefinitely. This may or may not be a desired effect based upon your businesses unique business rules.
  
  

Understanding the process flow

Below is an example of a four stage workflow process in order to administratively provision new SharePoint sites. This example illustrates a business process where multiple groups within a company may be involved with various stages of the provisioning process.

SharePoint Site Provisioning (Request Queue) - is used to capture new site provisioning requests.

SPSR Help Desk Work Queue (EA) - if the requestor selects the Help checkbox on the request form, the work item is copied to this queue before it is sent to the budget approver. This is used to manage cases where the requestor is not completely certain if SharePoint is the ideal solution.

SPSR Budget Approver Work Queue (FA) - in many large enterprises budget may need to be transferred from one department to another to cover the cost of site provisioning. This work queue allows for a person with budget authority to approve or reject a request.

SPSR Provision Core AD Group Queue (PA) - used to provision the three core Active Directory groups for a given site (Owners, Members and Visitors).

SPSR Provision Site Work Queue (PS) - this is the final stage where the site is built based upon the provided request information and the Active Directory groups are assigned.

Status Columns

Each work queue has these two columns assigned - "Approval_Status" and "Task Status".

The default values are: Pending and Not Started.

• Approval_Status - (underscore is used to prevent a naming conflict) gives groups responsible for managing queues the authority to accept or reject a request.
  
• Task Status - gives an indication of where a work item is with respect to completion.

The required conditions for a work item to go to the next stage is Approved and Completed.

Developing the Solution

The example assumes that you already have some proficiency with SharePoint development.

1. Build the SharePoint Site Provisioning Request list.
   
   
   

Note: You will notice that status columns have been added for each work queue (EA Approval Status, EA Task Status, FA Approval Status, FA Task Status, PA Approval Status, PA Task Status and PS Approval Status, PS Task Status). These columns will be updated by the associated secondary workflows and will be used to trigger the primary workflow.

2. Build a custom SharePoint Site Provisioning Request form with SharePoint Designer. (for help with custom forms see http://office.microsoft.com/en-us/sharepointdesigner/HA101191111033.aspx?pid=CH100667691033)
   
   
   
   
   Note: The status and workflow related fields have been removed from this form since they are not relevant to the capture process.
   
   
3. Build the four workflow task lists - SPSR Help Desk Work Queue, SPSR Budget Approver Work Queue, SPSR Provision Core AD Groups Work Queue and SPSR Provision Site Work Queue.
   

Note: the SPSR Provision Site Work Queue has one additional column - Provision URL Path. This value is used in the email notification that is sent to the requestor as the final step of the primary workflow process.

Non-standard Columns

• SPR ID - is used essentially as a foreign key to reference back to the parent item in the SharePoint Site Provisioning Request queue.


• Task Link - is used as a hyperlink point back to the parent request item.


• Task Group - is the group assigned to perform the work on the associated queue.
  

4. Create the primary workflow with SharePoint Designer (for help creating workflows see http://office.microsoft.com/en-us/sharepointdesigner/HA101005911033.aspx). In this example we will not go into the details for each workflow step, but rather cover only the key workflow areas.
   
   

You will notice below that the first condition in the workflow logic is triggered if the "Help" checkbox is true. Essentially, this action creates a work item in the Help Desk work queue with remaining steps being identical in if the "Help" checkbox is set to false. If SharePoint Designer allowed for multiple levels of nesting this workflow example could be simplified even further.

Action 1 - the first action sets the SRTaskItemLink variable for use in other actions. (In this example we will not cover every element in setting workflow variables. For help with this aspect please refer to http://office.microsoft.com/en-us/sharepointdesigner/HA101005911033.aspx). Notice the default value for Task Status is "Not Started" and Approval_Status is "Pending".

Action 2 - the next action sets the SRTaskURL variable.

Action 3 - this action creates a work item in the SPSR Help Desk Work Queue.

Action 3a - the SPR ID is set from the current item ID.

Action 4 - sets the default status values.

Action 5 - sets composes an email notification to the responsible group.

The remaining three stages are similar the stage illustrate above. Note that the workflow is in a hold condition until the Approval_Status is changed to Approved and the Task Status is set to Completed.

We will now work on the secondary workflows responsible for synchronizing the status columns between the workflow task lists.

Secondary Workflows

5. Create the secondary workflows. Basically you will need to create a secondary workflow for each work queue. In this example below we will show the step required to build one of the four required.
   
   
   
   Name your workflow and check only the "Automatically start workflow whenever an item is changed" checkbox.
   
   
   
   
   Action 1 - the first action sets the SPR ID workflow variable for use in Action 3.
   
   
   
   Action 2 - this is essentially an administrative step. Usability studies have shown that many end users will inadvertantly forget to set the Task Status field to Completed after they have either Approved or Rejected the request. Also, be sure to use the custom Approval_Status field.


Important Note: without an exit condition such as "...and Task Status not equal to Completed" will cause a race condition in SharePoint. This is caused by this workflow triggering a change event on itself.



Action 3 - this is the final (and most complex) step used for syncronizing the status columns between the two list. A limitation in SharePoint Designer prevents us from performing a comparision operation between an INT and a DOUBLE datatype. As a result we will be unable to reference SPR ID in the step below.




Notice the missing reference to the SPR ID workflow variable below. To workaround this limitation we will need to modify the XOML directly. At this point enter any integer value (such as 1) in the value field and save and close your workflow.



Notice the missing reference to the SPR ID workflow variable below. To workaround this limitation we will need to modify the XOML directly. At this point enter any integer value (such as 1) in the value field and save and close your workflow. Right click on your status update workflow file and open as text making the following changes represented in the code snippet below.



Now the reference to the SPR ID is available as shown below.

After creating a secondary workflow for each queue you can now test all stages of the Site Provisioning workflow process. The final step in the primary workflow is to send an email notification to the requestor.

As mention at the beginning of this article the SharePoint framework shown here could be used to facilitate practically any business process that requires multiple stages.

In my next BLOG we will cover interconnecting workflow processes between distinct and physically separated businesses.