SJEaton Posted December 18, 2017 Share Posted December 18, 2017 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 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 18, 2017 Share Posted December 18, 2017 @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 Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 18, 2017 Share Posted December 18, 2017 @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 Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 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 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 18, 2017 Share Posted December 18, 2017 @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 Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 Oh dear. How do I raise an incident? Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 18, 2017 Share Posted December 18, 2017 @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 Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 Thanks Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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. Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 Thanks @Victor, I'll wait for you to investigate further Sam Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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 ... Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 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 Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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... Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 @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? Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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... Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 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 Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 @Victor, I raised another topic yesterday that also relates to this whole linked requests thing.... Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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... Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 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 Link to comment Share on other sites More sharing options...
Victor Posted December 18, 2017 Share Posted December 18, 2017 @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. Link to comment Share on other sites More sharing options...
SJEaton Posted December 18, 2017 Author Share Posted December 18, 2017 great, thanks. I shall wait to hear from you Link to comment Share on other sites More sharing options...
SJEaton Posted December 21, 2017 Author Share Posted December 21, 2017 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 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 21, 2017 Share Posted December 21, 2017 @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 Link to comment Share on other sites More sharing options...
Victor Posted December 21, 2017 Share Posted December 21, 2017 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. Link to comment Share on other sites More sharing options...
.thumb.jpg.d5d3a83b710c9f83c4e4e8cccaba3f81.jpg)
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now