Suspend node not suspending

[Guest Paul Alexander]

I'm trying to get a BPM to suspend and wait for a request updated, but it doesn't seem to be working. 

What SHOULD be happening is that the request is resolved, then an email is sent to the customer, the timer stops, then the request is put in a 'suspend' state waiting for either a request update (from the user updating the request on the portal) or for the suspend node to expire. 

I've set up a decision tree to filter out WHAT happens (whether the suspend node expires or there is an update to the request), and it skips through this saying that the request has been updated, so the request is reopened immediately after being resolved.

What am I doing wrong?! 

 

 

 

 

 

[Martyn Houghton]

@Paul Alexander

Does it suspend at all when it first reaches the 4 day suspend and wait for request update?

We have had issue with this node as well especially in the fact that once it had been un-paused/expired once, you could not use it again, i.e. there did not seem to be a method to clear the fact that the node have been picked up a change and would not then re-pause.

Cheers

Martyn

[Guest Paul Alexander]

@Martyn Houghton

No, it seems to skip straight past the node first time (as in, it doesn't seem to suspend at all). But the second time it goes round, it DOES suspend and waits for an update. 

 

thanks

 

Paul

[Martyn Houghton]

@Paul Alexander

That's weird. On the second pass through on re-open, is suspending twice, i.e. once for resolution and once again for the update? I am wondering if it is suspending at all and the suspend you see is the one for resolution?

Cheers

Martyn

[Guest Paul Alexander]

Something else I've noticed is that, if I look at any of these requests in Service Manager, the blue 'the request has been updated' messages shows .....

 

 

 

If I press it, then come out of the request and go back in, the message shows up again. Is this related to the 'suspend' node? I can't say I've seen it before.....

[Guest Paul Alexander]

@Martyn Houghton

Actually...you're right! The 'wait for resolution' node DOES suspend, but the next 'wait for request update' doesn't (I realise in the graphic the name of the suspend note is 'Wait for status update' but in fact it's a 'suspend - wait for request update' node)

[Martyn Houghton]

@Paul Alexander

Sounds like the same problem we had with the 'Wait for Request Update', we where trying to use this node in a loop to check for a sub-status change, as there is no 'Wait for Sub Status Change' node but the BPM quickly looped to the maximum number of steps and the workflow fails, so had to abandon it.

@Victor @Steve Giller - was there any reply from development in the end under our ticket IN00158066, as to what constituents a request update and how this 'state' is cleared?

Cheers

Martyn

[Guest Paul Alexander]

I have another instance of the same fragment of nodes but this one DOES work after the initial go round (so, in this instance, the request was resolved, it DIDN'T wait for a request update but skipped through to the 'wait for resolution' node. It was then resolved again, and is now waiting for a request update....so this node DOES work sometimes....)

[Steve Giller]

Without seeing the settings for each node and decision branch it's not possible to narrow it down, but we can think of a few reasons why the above flow would either not suspend or would appear to have not suspended.

I know the Service Manager team have seen this and are looking into it, they'll post back here when they have more information.

[Victor]

@Paul Alexander @Martyn Houghton @Steve Giller

There is an aspect that I see is not covered by documentation. Wait For Request Update will pause a workflow and wait for a request update. I see this definition is a bit vague so I'll clarify it: This update is not any activity on a request, it is specifically an action that will register in the timeline as Update. Like this:

The node will only wait for this type of action, or better said, will only resume following an action of this type, any other action on the request (email, assignment, escalation, etc) will not count as an update as far as Wait For Request Update node is concerned. This might explain why it appears to work intermittently.

Now, as in why this did not work in your test, I can't say, as Steve said, we need to look in more detail to BP configuration and examples to see why and how your test did not work.

 

[Guest Paul Alexander]

Thanks @Victorand @Steve Giller

Do you need anything from me to help you investigate this?

[Steve Giller]

@Paul Alexander Not at present, thanks. If we need extra info we'll update you on here.

[Guest Paul Alexander]

I'm not sure if this helps, but I use a BPM template which has our 'reopen' loop (which is the bit which isn't working - above) as standard.

This is part of the reason that I can't understand why it works on SOME requests, but not on others. I'm sure that's no help at all, but i thought I'd mention it. 

[Guest Paul Alexander]

Has any investigation been done on this problem yet please? 

It seems to be causing us a lot of problems at the moment as SOME requests seem to wait for an update while others don't. I can't see any reason for it, but we seem to have a lot of requests which are reopening seemingly of their own accord.

Would it be better if I log it as an incident?

thanks

[Victor]

@Paul Alexander for some reason I was under the impression a support request existed for this... Yes, if you can, please raise a support request