Victor Posted May 14, 2018 Share Posted May 14, 2018 11 minutes ago, Dan Munns said: I am assuming that the Update A node in your screenshot sees the previous node as an update and the BPM moves on to Update B where it is truly in a suspend state and will not move until a further update (by user or analyst), is that correct? Am I correct in also assuming that the first update node is there to cover any requests that have had no updates since logging? Yes and Yes 11 minutes ago, Dan Munns said: Sorry but can you explain the logic of this? It is a bit convoluted and I really really try to avoid putting too much technicality in posts... Happy to explain you over a PM if you like but I much rather go with your above explanation for why the configuration... Link to comment Share on other sites More sharing options...
Dan Munns Posted May 14, 2018 Share Posted May 14, 2018 1 minute ago, Victor said: I much rather go with your above explanation for why the configuration... Thats cool. As long as I got it kind of right I can work it in my head when using it. I just don't like doing things if I don't understand how it works. Makes trouble shooting/fault finding a nightmare. Link to comment Share on other sites More sharing options...
Victor Posted May 14, 2018 Share Posted May 14, 2018 @Dan Munns you actually got it very right, spot on both! ... And you're also right, I should have tried to at least put some friendly description there ... Probably I just thought of the technical one which being quite complicated I said better without... *sigh... Link to comment Share on other sites More sharing options...
SJEaton Posted May 16, 2018 Author Share Posted May 16, 2018 Hi @Victor, thanks for the update and guidance, I'm just catching up after a holiday so will have a go when I get a minute and let you know how it goes. On 5/14/2018 at 1:41 PM, Victor said: I really really try to avoid putting too much technicality in posts I'm really really glad! I definitely like it all laid out in user friendly descriptions so my brain doesn't melt haha Sam Link to comment Share on other sites More sharing options...
SJEaton Posted May 16, 2018 Author Share Posted May 16, 2018 Hi @Victor, ok so I've tested this out and it does work in the fact that it does wait. However, when the update comes in from the linked request, it doesn't move the process on ie update the timeline with 'The BP is now resumed' (I left this in to see if it worked) or do the next steps in my test process. My test BPM is called 'HRA I Want to Appoint Process - v7.0 (to test linked requests suspend and update)' and it's on the 'On-boarding - New Starter' stage where I've configured what you suggested. The ref no of the test request is SR00037440 and the linked request it raised is SR00037443. The BP for the linked request (HRA Unlock Payroll) updates the original request timeline when a HT is actioned and this update is what I want to then move the original request process on to the next task. Hopefully you can take a look and advise what's missing? Sam Link to comment Share on other sites More sharing options...
Victor Posted May 16, 2018 Share Posted May 16, 2018 @SJEaton ok, I'll have a look... Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 @SJEaton I have a theory of why this did not work... may I ask you to run some (quick) tests, please? 1. Can you make a manual update on SR00037440? I suspect the process will resume after this... 2. Can you redo the test and for this test amend the "HRA Unlock Payroll" process and remove the "update linked request" node. Instead of this make a manual update on the request (like above)? Again, I suspect the process will resume following the manual update instead of the automated one... If both of the above are confirmed then most likely I will have to go back to dev team and te them updates form linked requests do not resume a "suspend wait for update" node... Link to comment Share on other sites More sharing options...
SJEaton Posted May 18, 2018 Author Share Posted May 18, 2018 Hi @Victor 1) yes it resumed when I did a manual update 2) the thing about this one is that it would defeat the object of what I'm trying to achieve i.e. the request owner for unlock payroll request wont have to worry about updating the I Want to Appoint request as the process will do that automatically Sam Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 2 minutes ago, SJEaton said: the thing about this one is that it would defeat the object of what I'm trying to achieve I know it does ... It was just to test my theory Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 @SJEaton so, I had a chat with our dev team and they confirmed a defect in which only updates from the user app (manual updates) or updates made via the portal will trigger a process resume. Update made via other sources, such as a linked request, do not trigger a process resume, and this is our issue... They are working to have it fixed now. So, if you haven't got a chance to test further, there is no need for it... Link to comment Share on other sites More sharing options...
SJEaton Posted May 18, 2018 Author Share Posted May 18, 2018 Hi @Victor I can confirm your theory is tested for 2). The manual update moved the request on. (SR00037947 was the test) Sam Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 @SJEaton thanks ... the devs already confirmed the defect (as I went ahead and presented the scenario to them) .. I do apologise I asked for the test and I was hoping my message (that is no longer necessary) got to you before you got a chance to do it... Sorry ... Link to comment Share on other sites More sharing options...
SJEaton Posted May 18, 2018 Author Share Posted May 18, 2018 No worries. Glad they've found the defect. Hopefully they can fix it soon Sam Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 @SJEaton just heard back from dev team on this, the fix will be available in next Service Manager update. Just keep an eye on this reference "PM00151314- Updating linked requests via BPM doesn't resume the linked requests BPM" just in case I miss it or I am late in updating you Link to comment Share on other sites More sharing options...
Dan Munns Posted May 18, 2018 Share Posted May 18, 2018 @Victor does that mean that updates from an authorisation task performed by a collaboration user will not move the BPM on either? Link to comment Share on other sites More sharing options...
Victor Posted May 18, 2018 Share Posted May 18, 2018 @Dan Munns mmm... how is that authorisation performed? Apologies, I should know this but I don't The only update that makes the BPM move forward is an update made on the portal, by a user/contact or a manual update made by a user via the user/live app. If the authorisation produces an update with a different "source" than the ones mentioned, then no, it won't move it forward... not until the fix is available... Link to comment Share on other sites More sharing options...
Dan Munns Posted May 18, 2018 Share Posted May 18, 2018 It will be from the email sent to authorisers (the hardcoded one). Its ok I will have to wait I guess. Link to comment Share on other sites More sharing options...
SJEaton Posted May 21, 2018 Author Share Posted May 21, 2018 Thanks @Victor On 5/18/2018 at 12:40 PM, Victor said: Just keep an eye on this reference "PM00151314- Updating linked requests via BPM doesn't resume the linked requests BPM" I can't find this? where should I be looking? Sam Link to comment Share on other sites More sharing options...
Victor Posted May 21, 2018 Share Posted May 21, 2018 @SJEaton you can't find it yet, this is why I said to keep an eye for it... as with any fix, it will be included in an update. Update release notes are posted in our announcements section: https://community.hornbill.com/forum/135-announcements/ Link to comment Share on other sites More sharing options...
SJEaton Posted May 29, 2018 Author Share Posted May 29, 2018 Hi @Victor, just checking I haven't missed this update? Link to comment Share on other sites More sharing options...
Victor Posted May 30, 2018 Share Posted May 30, 2018 @SJEaton no you haven't as the update with the fix for this has not yet been deployed. Link to comment Share on other sites More sharing options...
SJEaton Posted June 25, 2018 Author Share Posted June 25, 2018 Hi @Victor, after our update to build 1252 this morning I can confirm this is now fixed and works a dream Sam 1 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