SharePoint Designer Workflow vs. Visual Studio Workflows

SharePoint Designer Workflows

• Can not redeploy. Workflows designed using SharePoint Designer apply to a single site, and cannot be redeployed easily. (It is actually possible, but is a developer task.) Major limitation vs Visual Studio approach
• Numerous limitations to the structure and flow of your workflow. Examples include not being able to update multiple items, or see if the value of a field has changed - see here for more details. Major limitation vs. Visual Studio approach
• Simplistic ‘Outlook Rules’ approach to designing workflow logic. It works, but isn’t as flexible as Visual Studio.
• No dynamic task assignment. No task assignment based on availability, current workload, round robin, etc.
• No interaction with external systems. This has to be done as a development task.

Visual Studio Workflows

• Developer Task. You need a developer to do this.
• Awkward. The tools for developing workflows are still in their infancy. Debugging is particularly bad (read ‘effing painful’). Development of workflows is slow.
• Aspects are still pretty much undocumented.
• InfoPath and Workflow don’t really use the same data structures. Thus, data handling between them is awkward. Avoid Repeating Fields at all costs (e.g. lines on an invoice)

Both

• Workflows are Document Centric. (Or more correctly, ListItem-centric). An item (usually a document) ‘owns’ a workflow. A Workflow does not ‘own’ or ‘hold’ document(s). There is no equivalent of a ‘Workflow Attachments’ folder as in some other products. It is possible to bind multiple documents together using a common piece of meta-data (e.g. ‘Case Reference’), but the viewing of the process’ documents is troublesome - and probably via search. And it is possible to have processes for multiple documents - by have a separate workflow for each document. Thus, if you business process contains, say, 5 documents, then you’d need 5 workflows. This will also cause havoc when you start planning reporting on the workflows. Try to avoid processes which contain multiple documents.
• Documents can only have one of each workflow running against them.
• Rubbish tracking and reporting. Events just get recorded into a ‘Workflow History’ list. This does not support reporting on very easily - certainly not like a database table.
• Delay Steps do not work OOB. That’s right, you can’t build delay steps into your workflow without first installing a patch from MS Professional Services - one which we haven’t laid our mitts on yet. That’s right, bang go all of your escalation processes. Nobody would want to do that in a workflow, right?
• No view over all Tasks in environment. Users can be shown a list of all tasks in a single Site Collection, but not all Site Collections.
• Workflow host can’t be split of onto it’s own server. Or at least, I’ve never found a way. In systems with LOTS of workflows, this will impact performance.