The key to a succesfull SharePoint implementation is making the right choices. Not only about choosing which functionality to implement first - see Leveraging the SharePoint platform - what capabilities to start with - but also about making the right choices when you try to extend the platform. This blog series will focus on making the correct customization/design choices.
Let's explore one of the choices you have when looking at workflows in SharePoint.
SharePoint Designer for workflows vs Visual Studio Workflow Extensions
One of the most telling statements about this you can find on the SharePoint blog - "SPD is geared toward the Web Designer/Business admin. It's easy to learn, and you don't have to write any code. You can put together a lot of workflows with just sequence of actions and conditions."
One of the limitations of SharePoint Designer for workflow development is the fact that you need to design your workflows directly on your production server. There is no "easy way" to export a SharePoint workflow from your development environment and deploy it later on your production environment. If you want to do this you are up for some ugly hacking of the XOML code.
If you build your workflows using Visual Studio - you can quite easily build a SharePoint solution package containing the workflow and pass it from test to acceptance and finally to production.
You might also want to take a look at Workflow Development Tools Comparison
Related links:
- Guide to SharePoint workflow development
- SharePoint workflow link wrap up
- Creating a SharePoint state machine workflow
Next up in this blog series - creating one or more multiple site collections.
There is a way to develop portable SPD workflow. The fab 40 templates do this. They have embedded SPD workflow that is properly configured when you create a site based on them.
ReplyDeleteThe process maybe unsupported and it's cleary undocumented, but someone knows how to do it.