How to Create Custom SharePoint Workflows in Visual Studio 2008

Whereas simple workflows are possible using Microsoft Office SharePoint Designer, you will soon reach the point where you will need to use Visual Studio. In the third article in Charles' introduction to Workflows in Sharepoint, he demonstrates how to create a workflow from scratch using Visual Studio, and discusses the relative merits of the two tools for this sort of development work.

In this third article in my series on Windows SharePoint Services (WSS) 3.0.  I am going to demonstrate creating a more elaborate custom workflow with the tools available using Visual Studio 2008.

As a platform for designing and developing quick workflows SharePoint Designer is really valuable.  However, when your workflow design gets complicated or there is a need for some action or custom code which is not supported within this product then you will need to look at creating a workflow from scratch using Visual Studio.  Later on in this article I will discuss in more detail when you might need to look at Visual Studio as the platform for your workflow development.

To support the workflow I will be developing for this article I have expanded the sample site used in my previous article.  I have added a new document library titled ‘Product Authorisations’.  This library hosts a form which is completed to request that a new product line is authorised for sale.


The workflow we develop is going to be attached to this document library.

Workflow design

The idea for our new workflow is that once a new product request has been authorised, the Sales Team will be emailed and a new entry in the Products list will be created representing our new product.

A flowchart of the process looks like this:


Creating your workflow in Visual Studio 2008

  1. Start Visual Studio.
  2. Select File > New > Project.
  3. In the Project Types list select Workflow under your language of choice.
  4. Select the SharePoint 2007 Sequential Workflow template.
  5. In the Name field enter ‘ProductAuthorisations’
  6. In the Location field enter a directory to store your project.


  1. You will be prompted to give your Workflow a name and provide a local site for debugging.  Simply enter the URL for a suitable development site.


  1. Click Next.
  2. You will now be prompted to select the appropriate lists for use in debugging.  For this example you should leave the ‘automatically associate workflow’ option ticked.   Select Product Authorisations as the library to associate the workflow with and use the default workflow history and task lists.


  1. Click Next. Then select only ‘When an item is changed’ from the final screen of the wizard.
  2. Click Finish.

Your project will now be created and you should be shown the workflow designer.  This is the screen which allows you to configure the various elements of the process which will combine to form your workflow.  You will notice that an onWorkflowActivated action has been added to your workflow already. This action is required for your workflow to work within the context of SharePoint and it includes key elements such as setting the CorrelationToken.


You will notice from looking in the Toolbox that there are various different actions that can be dragged across to the workflow designer.  Some of these are specific to SharePoint such as CreateTask and others such as the basic Code activity are a part of the core Windows Workflow Foundation.

Because our workflow is conditional on the authorisation document having been approved the first thing we need to add is some conditional branching.

  1. In the Toolbox select the IfElse activity and drag this across to your workflow designer under the onWorkflowActivated activity.
  2. Select the ifElseActivity1 element and in the properties window change its name to ifApproved.
  3. Select the ifElseBrachActivity1 element and change its name to isApproved.
  4. Select the ifElseBrachActivity2 element and change its name to notApproved.


You will notice that our isApproved branch has a red exclamation marker.  This is indicating that there is a problem with this activity.  If you hover over the icon and select the down arrow you will receive a tool tip on what may be causing the problem.


In this case we can see that the issue is with the Condition property not being set.  The condition is used to evaluate which branch of the ifElse activity the workflow should use when running.  In our case we need to evaluate if the item is approved.

  1. Select the isApproved branch of your ifApproved activity and in the properties window select Code Condition from the Condition options.
  2. Expand the condition property and type IsItemApproved in the second Condition box.


You should automatically be taken to the code view in order to create the code to evaluate your condition.  A method called IsItemApproved should have been created for you.  This method should have EventArgs from the following class:

This class has a property named Result which allows us to specify whether or not our condition has been met.

  1. Copy the following code into your IsItemApproved method.

This code essentially evaluates the item’s Approval Status to see if it is approved.

  1. Drag a Terminate activity from the Toolbox into the notApproved branch of your ifApproved activity.
  2. Select this Terminate activity and enter the following text in the Description field of the Properties window:

    The item is not Approved.

This will simply stop your workflow is the item is not approved. Your workflow should now look like this:


The next step is going to be to perform the action required if the item is approved.  Looking at our workflow diagram we can see that we need to send an email and create a list item. However, in reality it would make sense to send the email AFTER the list item was created.  After all if the list item creation fails then we don’t want to have already emailed the sales team.

  1. Drag a Code activity from the Toolbox into the isApproved branch of our ifApproved activity.
  2. Select the Code activity and change the Name in the properties window to CreateProductsListItem.
  3. Double click on the Code activity.

This should open the code editor and create an appropriate ExecuteCode method for your code activity.  The Code activity allows a piece of entirely separate code to be run during the course of your workflow.  You are going to use this activity to create a new list item based on your product authorisation data.

  1. Copy the following code into the method created for you:

  2. Drag a SendEmail activity from the Toolbox into the isApproved branch of our ifApproved activity.
  3. Select the SendEmail activity and make the following changes in the properties window:

Your workflow should now be completed.  If you hit F5 to debug your project it should be built and deployed to the SharePoint site you specified when creating the project.

If you navigate to the Product Authorisations document library and create a new item you will notice that your workflow runs but terminates straight away, because the approval status is pending.

If you then approve the item you should see an email sent out and a new list item created in your Products list.

When should I use Visual Studio for Workflow?

As I mentioned earlier SharePoint Designer (SPD) is a great platform for developing basic workflows, however it has several limitations and in some cases these can mean that you have to look at Visual Studio as the solution for your workflow design.

In my experience the limitations of SPD are as follows:

  1. Workflows are bound to a specific list/site
     In SPD any workflow you create can only exist on the list (and in the site) that you created the workflow on.  You cannot design a workflow and then move it to another site.
  2. No code support
    You cannot write custom code within the SPD workflow tools.  You can write custom activities to include in SPD, but you would need to do that in Visual Studio anyway.
  3. No WSS Solution Package (WSP) support
    Your workflow will be deployed to the site via SPD and there is no support for packaging these as WSP files, which provide a more maintainable and upgradeable method of deploying customisations to SharePoint.
  4. No support for State Machine workflows
    You can only build Sequential workflows with SPD, there is no support for State Machine Workflows.

There are other reasons why you might choose to use Visual Studio (it might be an environment you are familiar and feel safe with) but if the points highlighted above are going to cause you a problem then you will definitely need to look at Visual Studio as your workflow development platform.  

Hopefully this article has demonstrated the flexibility that can be seen within a custom workflow created in Visual Studio.  The power is really in your hands as the workflow developer.  As you will have seen the workflow designer will let you run any custom code you desire within a Code activity, so even if there is no activity to achieve your goals out of the box, you can still write a solution which fulfils the exact business requirements that your workflow is designed to achieve.

In my next article in this series I hope to take a look at Event Receivers within SharePoint. What are they? How are they different to Workflows? And most importantly how can you create one?