Wait for Request Update Node not Waiting

[SJEaton]

Hi

I’ve created a linked request in the BPM - HRA I Want to Appoint Process - v7.0

It’s on the ‘On-Boarding – Internal’ stage and called 'Raise New Linked Request for Payroll & HRA'.   

For some reason it’s not waiting when it reaches the ’Wait for Request Update’ node and sending the Prompt email to Owner as soon as the request for Payroll & HRA is raised. 

The BPM for the linked request raised is called 'HRA Internal Transfer' and in this request there is an auto-task that updates the linked request and this is what it should be waiting for. 

Can someone please take a look and advise what I've done wrong?  Thanks

 

Sam

[Martyn Houghton]

@SJEaton

Can you attach a screenshot of the properties of the 'Wait for Request update' node from your process as that would give us some context of where it is in your workflow and the details of the node.

Cheers

Martyn

[SJEaton]

[Martyn Houghton]

@SJEaton

That looks like its all correct. Do you use the same 'Wait for Request Update' node elsewhere and does that work? Wondering if something has been introduced by a Service Manager or Platform update?

Cheers

Martyn

[SJEaton]

It's strange right?!!

OK so we do have a similar node in our HRA Ordering a New Mobile Device v2.0 and that was working fine but now seems to be skipping the 'wait for request update' too!!!

Sam

 

 

[Martyn Houghton]

@SJEaton

Does sound like something has been introduced in a recent change. Might be worth raising an incident with Hornbill formally as well.

Cheers

Martyn

[SJEaton]

Oh dear.  How do I raise an incident?

[Martyn Houghton]

@SJEaton

Normally you can do this via https://www.hornbill.com/support/?request/, enter your instance id and email address. Then you should get a screen similar to below and click on 'Get Help'. Or you can email them on hornbill.support@hornbill.com. Though it does depend on what maintenance/success plan you are on.

Cheers

Martyn

[SJEaton]

Thanks

[Victor]

@SJEaton @Martyn Houghton

35 minutes ago, Martyn Houghton said:

Wondering if something has been introduced by a Service Manager or Platform update?

The behavior of this suspend node has not been changed in latest platform or Service Manager updates. However,  looking at the code, it might be faulty but it always was... Need to do some investigation and report it to our dev team if my suspicion is confirmed...

@Martyn Houghton

11 minutes ago, Martyn Houghton said:

Or you can email them on hornbill.support [ ] hornbill.com

I'm afraid the only way to raise a support request is using the web form located on the support page you mentioned. We do not log requests from direct emails. Moreover, the mailbox is not actively monitored (due to automation tools in place) so direct emails might get noticed with delays or missed entirely... regardless, under normal circumstances, we won't be able to raise a request for you.

@SJEaton

You will be able to access the support page but you won't be able to raise a support request with us (the Get Help option is not available for you). This is because you are currently on Essentials Success Plan the option to raise a request with our support team is not available for this success plan I'm afraid.

[SJEaton]

Thanks @Victor, I'll wait for you to investigate further

Sam 

[Victor]

@SJEaton you mentioned the "mobile device" process used to work fine but not anymore... do you have any request reference where it did work? Just want to have a look at something ...

[SJEaton]

Hi @Victor

SR00010461 and the linked request was SR00010464.  These requests are cancelled as they were test requests but it was all working fine on this date.

Sam

 

[Victor]

@SJEaton nah... on SR00010461 the suspend for update node did not "work" (i.e. suspend) either... it can be seen on the timeline that after the linked request was created it went through the suspend node and created the "Send Activation Email..." node.... so the BP was actually waiting for the manual task so maybe the confusion it was waiting for update...

 

I'll run some tests but my theory is that if you have any timeline entry with the type of update the suspend node will behave as an update was made... the timeline entry can be anywhere... an example is, let's say, you have an update type entry in the beginning of the process... and somewhere towards middle or end of the process you have a suspend for update node... because the suspend node will look for an update entry regadless on when the update was made it will not suspend... and because we have an update in the begining... well, it won't work...

The way it should work is that the suspend node should look for an update only made after the suspend was initiated...

[SJEaton]

@Victor OK we did do lots of tests and were sure it was working ok so I'm completely miffed.  Anyway, yes I understand what you are saying, so how do we suspend and look for an update only made after the suspend?      

[Victor]

@SJEaton

Just now, SJEaton said:

how do we suspend and look for an update only made after the suspend?

Seems you/we can't currently... I raised this internally and waiting for our dev team feedback...

[SJEaton]

That's just weird. I thought the whole point of the 'suspend and wait for request update' was that it waited for the next time it was updated following that node??  I'm sure this is used elsewhere in other processes but can't think of them off the top of my head.

Sam

[SJEaton]

@Victor, I raised another topic yesterday that also relates to this whole linked requests thing.... 

 

[Victor]

@SJEaton

37 minutes ago, SJEaton said:

I'm sure this is used elsewhere in other processes

Could be... it will work if you don't have a timeline entry of "Update" type prior to the suspend node... so possibly wherever you used elsewhere you didn't have this scenario...

[SJEaton]

Hi @Victor 

The suspend and wait for request update node' really is misleading then and there's no purpose to it.  Do you think something can be done to make it work the way expected i.e. that the suspend node looks for an update only made after the suspend was initiated?

Sam

 

[Victor]

@SJEaton ... I did mention above that I bought this behavior in the attention of our developers... I do think is a faulty design and yes, I was thinking the same in my above comment that the node should cater for updates made after suspend was initiated...

So, yes, most likely something can be done, currently, I am waiting for dev team feedback on this.

[SJEaton]

great, thanks.  I shall wait to hear from you 

[SJEaton]

Hi @Victor, sorry to chase but any ideas on the timeline for a response from the developers on this?  I'm being pressed to get a fix as we need to introduce the linked requests/wait for update function in our 'I Want to Appoint' process as soon as possible.  Unless there's a workaround you can suggest in the interim?  Thanks

Sam  

[Martyn Houghton]

@SJEaton

Is it a manual update on the original requests that then resumes the workflow? If it is you could look at having a manual activity which is completed when the appropriate action is taken on the linked request, or look at using a sub-status for this period of the request lifecycle, so you can use the wait for status change node.

Cheers

Martyn

[Victor]

2 hours ago, SJEaton said:

any ideas on the timeline for a response from the developers on this

@SJEaton the dev team acknowledged the defect we described in this thread (basically this: because the suspend node will look for an update entry regardless on when the update was made it will not suspend). Thjey are now working to have it fixed. I'm afraid I don't have any ETA for this at the moment. I understand that the fix is important to you and I am sorry for the trouble it might case but I am unable to prioritise it. However, as soon as there are any updates on this we will let you know.

Meanwhile, perhaps @Martyn Houghton suggestion would prove suitable. I'll also have a look to see if there are any other alternatives.