As most of you know, I try to avoid SharePoint Designer like that creepy distant relative at family reunions who always gives you the heebie-jeebies. But lately we've had some clients who insist on doing everything "out of the box", so I've had to grit my teeth and, with great trepidation, fire up ye old SPD for some simple workflow creation.

For the most part, SPD workflows are fairly innocuous, with the most pain coming from beating your head against the wall trying to make it do something simple in seventeen steps that you could do with three lines of code in Visual Studio. That being said, there are some real annoying bugs that crop up from time to time, like this one: I create and deploy a workflow as the System Account but users can't edit their own tasks in the Tasks list. They get an "Access Denied" error whenever they try to edit the task (which, being an SPD-generated task, opens a custom .aspx page instead of the standard editform.aspx page). After some intense LiveSearching, I found a post from Paul Galvin on this issue. From where I stand, this definitely looks like a bug but I can't confirm whether it's version dependent (pre-SP1, post-SP1, etc.) because all the machines I'm testing on are patched to at least the Infrastructure Update level.

Unfortunately, Paul's workaround method (saving the workflow locally) didn't work for me – the 'Save As…' options were all greyed out. After futzing with it a bit, I tried something different – I checked the workflow out, then checked it back in (right-click the workflow folder in SPD, Check-Out/Check-In). Voila! Users can now edit their own tasks. Bizarre. It's worth noting that this only happened for me on workflows that were created by the System Account – regular users with Site Owner permissions did not experience this problem (your mileage may vary).

Now, if I could only go back to doing workflows the *right* way (that is, in Visual Studio instead of SPD), my day would be made…