- Scott

Point 1 can be extended to include the business users – often (though not always) they don’t understand their own processes either. When you start looking into what they need, you end up with fantastically complex workflow – which can be difficult in SPD.

Regarding Point 4 – Have you tried creating a Visual Studio workflow? Microsoft tried to drive folks down the route of using InfoPath forms for workflow interaction – but they suck! It’s an amazingly bad development experience. Fields that won’t populate, some that won’t return data, some sections that return properties with values in, and others return XML.

ASP.NET forms are (or at least were, last time I looked) basically undocumented, though there is a Codeplex project which might make them a viable solution.

God help the soul who tries to get modification forms working.

SharePoint designer – now it is better, actually, for simple processes and a ‘business user’ type of user. Shame that the workflows can’t be redeployed, so we can reuse them, or try them on a test system first.

We’ve been using K2 for workflows. It’s not perfect – but InfoPath works better with K2 workflows, ASP.NET workflow forms are easier to write, and we’ve not had any problems with the host not doing things when it should.

So, I guess my experience has been problems with business overestimating their readiness to use workflows, and that the tooling that came out with SharePoint 2007 is less than ideal.