Suspend for new request owner

[Peter Clough]

I'm building a workflow that has a Suspend node set to Wait for New Request Owner. However, I'm unclear on if I'm misunderstanding the process or if there is an error. The capture has an assign page, which is mandatory (assigning to user is not forced). When this node is reached, it always suspends, even if the job was assigned to an owner during capture (this makes sense).

If the request is assigned to my team, with no owner, and I subsequently Take Ownership, the suspend doesn't release. If the request is assigned directly to me when logging, and I subsequently return the job to no-owner, and re-accept it, it also doesn't release. If it is initially assigned to someone else, and I then assign it to me, it releases. I've also had a colleague take ownership and the same thing happens.

Quote

This flowcode operation suspends the bpm instance and waits for the request to be assigned to a new owner before being allowed to continue. If the request has not previosuly been assigned, it will allow the business brocess to continue once an owner has been assigned to the request.

According to the help text in the workflow designer itself, it should release if the request has previously been assigned, and when it gets a new owner. It's simple enough put a decision first to only suspend if there's no owner already, but the behaviour where it does not release when the first person takes ownership seems aberrant to me.

[Steve Giller]

1. If the request is assigned to my team, with no owner, and I subsequently Take Ownership, the suspend doesn't release.
   • There may be a difference between assigning a Request and Taking Ownership of a Request - linguistically there is, I'll have to check internally about whether this applies logically, too. Personally I'd expect the Workflow to move on here.
   • What do you see if you assign it to yourself rather than Taking Ownership?
2. If the request is assigned directly to me when logging, and I subsequently return the job to no-owner, and re-accept it, it also doesn't release.
   • This may be unintuitive, but is not assigning a new Owner. I will check the expectation internally, but it is the behaviour that I would expect.
3. If it is initially assigned to someone else, and I then assign it to me, it releases.
   • This is absolutely what the node is designed for.
4. I've also had a colleague take ownership and the same thing happens.
   • I'm not clear on which "the same thing" of the 3 above you're referring to here.

[Peter Clough]

1. I also tried assigning it directly to myself from no-owner, with the same result, it didn't move along.

2. Yeah, this one is easy enough to decision node around, makes sense to me.

3. 

4. That would have been useful information. I had them test situation 1.

5. (Bonus round) I set it as no-owner in the logging, then assigned it directly to someone else within the team, and this also failed to progress.

6. If I assign it during capture to a completely different team (still no owner), and then assign it across teams to myself, then it still fails. (Unrelated, when I was testing this, I realised I am only auto-added as a member to the request when it goes to a different team initially.)

[Steve Giller]

OK, so from that it appears that changing from "No Owner" (specifically "Never had an Owner") to "An Owner" does not appear to register as "New Owner" and you have to assign it twice to different Owners to progress.

That doesn't sound like intended behaviour, I'll look into this and report my findings if I can replicate this.
It will have to be next week, though, I'm afraid.

[Peter Clough]

Thank you very much.

[Peter Clough]

Good morning, @Steve Giller. I just wanted to check if you'd had the chance to look into this? It's come up in another process I'm currently building, and still seems to be an issue.