Three things that still annoy me about Workflow in SharePoint

There is no support for tracking services. Or rather, if there is, nobody is saying. You’re stuck with ‘History’ lists, which suck. All I want is a table I can query, and that I’ll expose that via the BDC. But without this, workflow in SharePoint is nothing more than a toy, which isn’t fair given the effort put into it. I know that Microsoft don’t want to step on K2′s toes – fair enough. Truth be told, I was wondering what K2 were going to do, figured that they must be running scared – but having seen Black Pearl, I see that they’ve been running hard, and have a good lead. A SQL tracking service won’t erode that lead.

Repeating fields in Infopath forms are unusable. Nobody knows how to do this. I spent ages working on it, but I didn’t get anywhere. I couldn’t write to these properties through the task properties at all. Indeed, the whole TaskChangedProperties.ExtendedProperties hash is daft. Forcing everything to flatten, well, sucks. Can’t I have a stream? Or a node-child tree of some sort? I mean, is it surprising to want to send InfoPath forms to/from a workflow task and a library? You know, use the workflow for routing, and the xml form in a library as the data store? That should be easy – it’s not.

Debugging workflows is hard. I mean, apart from Visual Studio crashing as I connect it to the appropriate service, there is a question over actually being able to get meaningful error messages out of workflow, and getting it able to breakpoint in the right places. In fairness, this is a complex thing. I have no idea how I’d set about allowing debugging in Visual Studio, say, after a Delay activity had expired. But it would be cool to have something a bit better.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>