Right, so I had a suggestion from Nick Swan, and it was a good one, so I gave it a try.

What he said was:

With OnTaskChanged there is the BeforeProperties and AfterProperties variables.

In the event can’t you set the AssignedTo in the AfterProperties?

This seemed perfectly reasonable – and I hadn’t thought of it already, so it was worth a try (wood/trees obscuration).

I created a workflow that consisted of 3 steps – a Create Task step, a While Loop (that is always true) and in the While, I put an onTaskChanged event step.

Creating the task, you set the assignee using an SPWorkflowTaskProperties object. Here is my line for doing that:

TaskProperties.AssignedTo = "MOSS\Domain Users";

That’s pretty clear. I then wrote code to set the AfterProperties of the onTaskChanged event:

TaskAfterProperties.AssignedTo = e.Identity;

Typically, e.Identity is something link “MOSS\burnsa”. I’ve checked. And that’s what I’d expect it to be.

So, the workflow enters the while loop – which as I say, deliberately never exits – an the workflow awaits a change in the task. When that change comes, I’m going to look at the AssignedTo field of both the BeforeProperties, and AfterProperties. Oh, yeah, and I deliberately WASN’T changing the assignee within the task.

BeforeProperties – Expected: “MOSS\Domain Users” – Actual: null

AfterProperties – Expected: “MOSS\Domain Users” – Actual: “16”

…and setting the AfterProperties with e.Identity did damn all. WTF?

I could understand that setting AfterProperties with e.Identity might not work – although it seems a reasonable thing to try and do – but the AssignedTo fields being null, and then 16? Don’t make no sense.

Oh, further – I tried again, but this time setting the assignee as my change to fire the onTaskChanged event. This time the AfterProperties assignedTo field was ’13’, so clearly it is some sort of identity – just not an obvious or particularly useful one.