You should have a fully functional development machine with SharePoint 2010 installed and configured. You also need Visual Studio 2010 IDE installed on the same development machine. We are using a team site template for our examples.

Use the custom list template and create a list from the SharePoint user interface called Credit Approval. The following table provides information on fields and its properties:

The following screenshot shows the end result:

Every SharePoint workflow project starts with an onWorkflowActivated activity. This activity is a mandatory activity and hence Visual Studio added it to the designer automatically. By default, this activity is bound to a variable called workflowProperties of type SPWorkflowActivationProperties. The workflowProperties provides information about the current workflow context, the item that initiated the workflow, the list to which this workflow belongs to, the originator user, and other information. SharePoint workflow runtime fills in all these values for us to make use of. For all the items that workflowProperties provide, refer to: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.workflow.spworkflowactivationproperties.aspx.

Using the workflowProperties we were able to get access to the list item that initiated the workflow and from this, we were able to access the item information in the code and create the conditions for the IfElse activities. The code is pretty simple such that it checks the values that were put in and makes decision on them.

The logToHistoryListActivity is a SharePoint specific activity that logs information to the history list. This activity behind the scenes calls the method LogToHistoryList from the ISharePointService interface, which is implemented in the assembly Microsoft.SharePoint.Workflow.dll. The following code shows the method signature for this method:

void LogToHistoryList(
Guid workflowId,
SPWorkflowHistoryEventType eventId,
int userId,
TimeSpan duration,
string outcome,
string description,
string otherData
)

In this method, you can specify an event type like the one workflow started, a workflow comment, and others to group your comments to a specific category. For more information on event types that can be passed to this method, refer to MSDN at: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.workflow.spworkflowhistoryeventtype.aspx.

The ISharePointService interface enables activities to exchange data outside of the workflow instance. In this case, writing to the history list. There are other methods like SendEmail, SetState that are part of this interface as well. Refer to MSDN for more information at: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.workflow.isharepointservice_members.aspx.

In Visual Studio 2010, all the SharePoint project items like Event Receivers, workflow projects, or content types will have a similar structure such as having a feature, a folder for the project item, and so on. When our workflow project was created, Visual Studio added a feature folder with Feature.xml file and a Workflow1 folder that contains the Elements.xml, Workflow1.cs, and Worlflow1.designer.cs. The last two files make up the activities of the workflow and the code associated with these activities. Like with Event Receivers, the Elements.xml file provides metadata information about the workflow to the SharePoint. You can name this file anything you want. But Visual Studio, always names it Elements.xml for all of the SharePoint templates when you first create the project. In here you set the attributes like the workflow name, the class file, and assembly that contains the code and so on. You can also set the association form, the initiation form, and the task form that are associated with the workflow. Since our workflow did not have any of these resources, we did not make any changes. All the attributes of the Elements.xml are as follows:

<Workflow
Title="Text"
Name="Text"
CodeBesideAssembly="Text"
CodeBesideClass="Text"
Description="Text"
Id="Text"
EngineClass="Text"
EngineAssembly="Text"
AssociationUrl="Text"
InstantiationUrl="Text"
ModificationUrl="Text"
StatusUrl="Text"
TaskListContentTypeId="Text" >
</Workflow>

For more information on the descriptions of all the elements of the workflow Elements.xml file, refer to MSDN at: http://msdn.microsoft.com/en-us/library/aa543564.aspx.

In the project creation wizard, we set our sequential workflow as a list workflow. This information can be found in the .spdata file located in the Workflow1 folder. By default this file is hidden. To list this file in the project explorer, toggle the Show All Files menu item from Project menu. The .spdata file is a SharePoint project metadata information file. This is of XML format. You should not manually change this file as it may get overwritten by Visual Studio when you make changes to the project structure like adding and removing items to and from the project. This file is used during the packaging process. It contains information about the SharePoint project item that is in the solution. You can also verify that property from the properties window of the Workflow1 folder. The other items that we set during the project creation wizard can also be verified in the properties window. You can see the history list and task list associated with the workflow. The target list property specifies the list that the workflow is associated with. This is only for debugging purposes. You can always associate the workflows to different lists after it is built and deployed. You do the association with the target list via SharePoint user interface or through object model code using Feature receivers. You can also associate it to a content type and deploy it.

When we build and deploy a workflow to a production environment, you have a couple of ways to associate the workflow with the content type, the list or with the site:

Here is the manual way to associate a workflow to a list.