The concept of workflow is not a new one and many commercial products on the market have been offering solutions for years, but at a very high cost. As most of you know by now, Microsoft was started working on this problem since the creation of the .NET framework 3.0 with the addition of WWF (Windows Workflow Foundation).
This has become the basis of workflow for most new Microsoft products like Office 2007, Project Server 2007, CRM 4.0 and MOSS 2007. Sharepoint specifically has many entry points into WWF and can basically be broken into the following levels of complexity:
It all starts with an object and a content type. Workflow's need to be attached to object so that they know what they are interacting with and there are basically two types of objects in Sharepoint, a list or a document library. Content types define what metadata is stored with an object and is vital in building a useful workflow. Even the default object instances like "Contacts" or "Tasks" have content types associated by default. Therefore the basic steps required to build a workflow is the following:
Start by creating a document library in a Sharepoint site and add some content to it.
The next step would be to open an instance of SPD (Sharepoint Designer). Select "Open" from the file menu and point it to the site containing the document library.
To create a new workflow, select "New" --> Workflow from the file menu.
This action will initiated a wizard that will start up and guide you through the process.
A number of options are available to configure on this screen:
Once the initial options have been configured, select the "Next" button on the wizard to continue.
The second phase of the wizard basically consists of an design pane that is used to create the logic of the workflow. Think of it as writing and "If Else If" statement in code, without actually having to write it yourself.
Also keep in mind that this is only the first step of logic in the workflow and additional steps can be created by selecting the "Add Workflow step" option on the right hand side of the screen.
Let's start by taking a look at the "Conditions" part of the logic first. This would map onto the "IF" part of a virtual script.
When selection the drop down option called "Conditions" a number of options appear that allow you to define a condition for comparison to determine if this workflow should initialise or not. The workflow will always be invoked (Hydrated) when the events connected to he object fires, like "New" or "Edit", but the condition will determine if this particular workflow will be initialised.
These condition can range from comparing dates to specific file values connected to the document. This is were the importance of the content types come in. If you did not spend sufficient time initially to determine what meta data needs to be associated with a particular document and built this as a content type associated with the document, then at this particular point the workflow becomes difficult to build. I personally believe this is why many people believe that SPD is not sufficient to build workflow's in Sharepoint.
Keep in mind that specific values can be compared against each other by selecting the "Hyperlink" options that appear and then supplying either metadata fields or hard coded values for comparison. Additional branch logic can be created by selecting the "Else If" branch option further down the screen.
It is also possible to create "AND" and "OR" scenarios by selecting the "Condition" option more than once.
Now that the logic has been determined, it is time to decide what to do if the logic is "True" by setting the actions.
To create an action for a particular condition is a simple matter of selecting the action from the drop down list called "Actions". In a similar fashion to the conditions, this will create "Hyperlink" options that can be configured by selecting them. Keep in mind that you always want to us metadata fields that come from the content type instance associated with this particular "Document" or "List Item" that invoked the workflow.
There are too many options to discuss them in detail and you will have to experiment and play with them to see what is available and how each of the options work. There are also a lot more options available by selecting the "More Actions" option from the drop down list as illustrated in the image below. Also keep in mind that some of the options only apply to lists and others only to documents.
For Example: When selecting the option called "Send and Email", do not hard code the email address by typing it into the action, but rather retrieve the email address from an meta data field associated with the content type. Assuming that you built it into the content type to start with.
It is also possible to add multiple actions to a condition by selecting the "Action" option more than once.
Once this step has been completed with its conditions and actions you need to determine if you need more steps. This was only the first step in the workflow and optionally more can be added by selecting the "Add Workflow step" on the right hand side of the screen.
When you have completed building the workflow, select the button called "Check Workflow" to determine whether your workflow will compile and the logic actually works. If you get the "All Clear", then select the "Finish button" to build the workflow.
You will also notice that a new folder structure gets created in SPD called "Workflow's" that did not exists previously. This allows you to edit the custom workflow in future by editing the "xoml" file in the folder structure.
There is obviously a lot more that can be written about writing custom workflow's in SPD, but I hope this blog gives you enough of a starting point to start experimenting. There are some additional links below written by some other authors on this site relating to workflow's and Sharepoint
This has become the basis of workflow for most new Microsoft products like Office 2007, Project Server 2007, CRM 4.0 and MOSS 2007. Sharepoint specifically has many entry points into WWF and can basically be broken into the following levels of complexity:
- Built-in or Downloaded workflow's - these come standard with Sharepoint or can be installed with add-on templates.
- Sharepoint Designer - this tool allows you to customize many aspects of Sharepoint including custom workflow's.
- Visual Studio 2005/2008 - this is the ultimate tool for building workflow's, but is quite often overkill for what is required.
It all starts with an object and a content type. Workflow's need to be attached to object so that they know what they are interacting with and there are basically two types of objects in Sharepoint, a list or a document library. Content types define what metadata is stored with an object and is vital in building a useful workflow. Even the default object instances like "Contacts" or "Tasks" have content types associated by default. Therefore the basic steps required to build a workflow is the following:
- Create an instance of an object like a "Document Library" in Sharepoint.
- Define the meta data required and build it into a content type. Associate the content type with the object.
- Build the workflow using SPD or VS and bind it to the object.
Start by creating a document library in a Sharepoint site and add some content to it.
The next step would be to open an instance of SPD (Sharepoint Designer). Select "Open" from the file menu and point it to the site containing the document library.
To create a new workflow, select "New" --> Workflow from the file menu.
This action will initiated a wizard that will start up and guide you through the process.
A number of options are available to configure on this screen:
- Name - each workflow requires and unique name to distinguish it from other workflow's in Sharepoint.
- Bind Object - the workflow needs to be bind to and object that exists in the site that was opened in SPD.
- Start Settings - the workflow is started by events triggered by the object. This can be "New" or "Edit" and is defined by the checkbox selections available.
- Variables - custom variables can be created to store values that can be used throughout the steps that will follow. These can be used later in phase 2 of the wizard.
- Initiation - it is possible to define questions that the user will be prompted with when the workflow is initialised. The responses can be used to determine the flow or outcome of the workflow.
Once the initial options have been configured, select the "Next" button on the wizard to continue.
The second phase of the wizard basically consists of an design pane that is used to create the logic of the workflow. Think of it as writing and "If Else If" statement in code, without actually having to write it yourself.
Also keep in mind that this is only the first step of logic in the workflow and additional steps can be created by selecting the "Add Workflow step" option on the right hand side of the screen.
Let's start by taking a look at the "Conditions" part of the logic first. This would map onto the "IF" part of a virtual script.
When selection the drop down option called "Conditions" a number of options appear that allow you to define a condition for comparison to determine if this workflow should initialise or not. The workflow will always be invoked (Hydrated) when the events connected to he object fires, like "New" or "Edit", but the condition will determine if this particular workflow will be initialised.
These condition can range from comparing dates to specific file values connected to the document. This is were the importance of the content types come in. If you did not spend sufficient time initially to determine what meta data needs to be associated with a particular document and built this as a content type associated with the document, then at this particular point the workflow becomes difficult to build. I personally believe this is why many people believe that SPD is not sufficient to build workflow's in Sharepoint.
Keep in mind that specific values can be compared against each other by selecting the "Hyperlink" options that appear and then supplying either metadata fields or hard coded values for comparison. Additional branch logic can be created by selecting the "Else If" branch option further down the screen.
It is also possible to create "AND" and "OR" scenarios by selecting the "Condition" option more than once.
Now that the logic has been determined, it is time to decide what to do if the logic is "True" by setting the actions.
To create an action for a particular condition is a simple matter of selecting the action from the drop down list called "Actions". In a similar fashion to the conditions, this will create "Hyperlink" options that can be configured by selecting them. Keep in mind that you always want to us metadata fields that come from the content type instance associated with this particular "Document" or "List Item" that invoked the workflow.
There are too many options to discuss them in detail and you will have to experiment and play with them to see what is available and how each of the options work. There are also a lot more options available by selecting the "More Actions" option from the drop down list as illustrated in the image below. Also keep in mind that some of the options only apply to lists and others only to documents.
For Example: When selecting the option called "Send and Email", do not hard code the email address by typing it into the action, but rather retrieve the email address from an meta data field associated with the content type. Assuming that you built it into the content type to start with.
It is also possible to add multiple actions to a condition by selecting the "Action" option more than once.
Once this step has been completed with its conditions and actions you need to determine if you need more steps. This was only the first step in the workflow and optionally more can be added by selecting the "Add Workflow step" on the right hand side of the screen.
When you have completed building the workflow, select the button called "Check Workflow" to determine whether your workflow will compile and the logic actually works. If you get the "All Clear", then select the "Finish button" to build the workflow.
You will also notice that a new folder structure gets created in SPD called "Workflow's" that did not exists previously. This allows you to edit the custom workflow in future by editing the "xoml" file in the folder structure.
There is obviously a lot more that can be written about writing custom workflow's in SPD, but I hope this blog gives you enough of a starting point to start experimenting. There are some additional links below written by some other authors on this site relating to workflow's and Sharepoint
