Loving Windows Workflow, hating Windows Workflow

I've been messing around with Windows Workflow lately and it's a bit of a love-hate relationship. Here's what I love, the fact I've got a workflow runtime that I can host in any application and, even better, it costs nothing. Hosting the runtime and persisting workflows to SQL Server is also reasonably straightforward, although I'm not sure my implementation is rock solid (I'm sure I'll find out if/when we go live). I love the fact I can develop workflows in Visual Studio and I can drop into C# whenever the activities provided don't quite do what I want. I love being able to write my own activities so I can parcel up commonly used functionality. I love being able to plug activities and properties together without writing any code. But then I'd like to think a business person might be able to design workflows and I can't see them picking up Visual Studio to do that. OK, I can host the Designer as well, but that's a pretty big job that I don't have time to do. I guess we could look at using SharePoint or BizTalk, but that would rather defeat the purpose of using Windows Workflow, which is primarily the cost. This seems to be the major problem workflow has always faced, making it simple enough for your average business person to understood (not suggesting they are simple of course...) but powerful enough so it can be used for real integration work. Coming from a background of using Metastorm e-Work there's a few obvious things missing from Windows Workflow that are available in e-Work. One is roles management, the other is easy forms integration. I guess both can be achieved but I need to investigate how easy it will be to do them, especially integrating forms in a fairly generic way. There is a good reason for not providing these features, since Windows Workflow is meant to be database and client platform agnostic. As ever, making a product as flexible as possible tends to make it somewhat complex and I think Windows Workflow has turned up the flexibility to 11. I have a few other niggles. Versioning doesn't seem to be supported. Workflows are persisted using .NET serialization so rebuilding a workflow assembly can cause any running workflows to fail. In fact I've had situations where I'm unable to do anything with a workflow, even terminate it. One other problem is there seems to be no simple way of getting data in and out of a workflow, without designing this data exchange into the workflow itself, something I was hoping to avoid since I was hoping to be able to do it in a generic way. But overall, given it's a version 1 product, I think Windows Workflow is pretty cool. Hopefully some of my problems are just caused by not understanding how it all fits together, so it's time for me to go and read a book.