One of the major selling points of SharePoint is the power of workflows. Designing very basic sequential workflows in Sharepoint Designer 2007 is a very straightforward task using the workflow designer wizard. But unfortunately straightforward is the key word here, as you are limited by the functionality available to you in SharePoint Designer. Simple tasks (e.g., update an item, send an email, etc.) are doable, but, for example, you can’t do any string manipulation other than building “dynamic strings”. So even creating a suitable subject line to an email can require a complicated collection of variables and such like. SPD workflows are also very much “single use” – i.e., they start, they run, they finish. They can wait and so on, but complicated business logic is pretty difficult to program. At that point, you’ll need to get involved with Visual Studio. That’s not without its difficulties, however, and as someone coming from a Visual Studio software background, creating workflows can be a minefield. Certain expectations you may have with Winforms just go completely out the window.

So here are some observations, hints and tips that I’ve picked up during my time with workflows and Visual Studio. Note that I’m using Visual Studio 2008 on an all in one MOSS2007 box (i.e., my development machine) to write these workflows. VS2008 does all of the debugging and deployment for you – if you’re on VS2005 then the process is a little different, as you have to manually develop the XML files that make up the package (which is beyond the scope of this).

1. Workflows don’t run at all – For security reasons, the workflow engine might not run at all if the web application pool is running as an administrative account. You can change the application pool to a network service in central administration.
2. Workflow failed to start (retrying) – this is a horrible error message. First thing to check is that the correlationtoken is set properly – in theory it should be as VS wouldn’t let you start debugging if it wasn’t. For anyone trying to get their head around what a correlationtoken is, don’t fret too much – it’s just a unique “key” that identifies the workflow. For your WorkflowActivated activity, you could set the token as “WorkflowActivatedToken” and then set the OwnerActivityName to the root class of your workflow. You can use the same correlationtoken for all activities in your workflow EXCEPT to say that logical units of the workflow (e.g., things surrounding the creation/use of tasks etc.) should get a separate token.
2b. Note: If you change the name of your class i.e., from Workflow1 to MyAwesomeWorkflow, Visual Studio unhelpfully does NOT update the workflow.xml file – you should do this manually
2c. Note: Sharepoint does a lot of logging some helpful, some not. If you trawl through the logs, you’ll usually get a step in the right direction to tracking down your errors. The logs are by default in : %Program Files%\Common Files\Microsoft Shared\web server extensions\12\LOGS
3. Activity/workflow properties can be empty -  In the properties of each your activities/methods, you don’t need to fill in all of the details. In fact, most of them will be empty, e.g., a method doesn’t necessarily need a MethodInvoking method if you don’t need to do anything more complex with it. In fact, my experience is to be as minimal as possible. By setting some apparantly insignificant properties or asking VS to create your eventhandlers, you can end up with a lot of extra code that you just don’t need. Always pick through the codefile and identify things that can be simplified or removed.

I’ll add more as I come across them, but for now here is a useful link for basic workflowing in Sharepoint / MOSS 2007 and Visual Studio 2008 which has a lovely video you can watch.