Sharepoint workflow vs Windows workflow

Question

We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.

Answer 1

They are the same thing. The current Windows Workflow Engine was created for SharePoint.

Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.

Here is a link describing the upgrade in 4.0.

Answer 2

SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.

In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).

SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.

Answer 3

Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.

SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:

• Workflow instances are persisted in the content database
• Communication with the user is through SharePoint tasks
• Every workflow instance is tied to a list/library item
• Tracking is not implemented

If these choices are to your liking then by all means use the SharePoint workflows.

If not then implement your own host and make your own decisions.

Answer 4

As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).

Answer 5

You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.

1. Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
2. Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
3. Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.

I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.

Answer 6

It's basically the same technology. If you know one you can easily work with / switch to the other.

When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)

Your SharePoint Server will act as a host for your workflows.

The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.

As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.