James Ainsworth Posted September 13, 2017 Share Posted September 13, 2017 Hi @Gary@ADL The 'No Match' expression on you decision node should be changed to look for the outcome of Expired if you are using the Expired option on the 'Suspend and Wait for Status Change' operation. However, we did identify an issue with the Expiry option on this operation where the decision node was not correctly evaluating the expiry. A fix was provided but I am not sure if this has already made it to the live environment. If not it will be in the next update. James Link to comment Share on other sites More sharing options...
James Ainsworth Posted September 13, 2017 Share Posted September 13, 2017 Hi @Gary@ADL The issue I mentioned in my previous comment ended up not being an issue so you can ignore that. You should be able to go ahead and look at the Expiry option for your Suspend and wait for status change and the following decision node. Regards, James Link to comment Share on other sites More sharing options...
HHH Posted September 12, 2018 Share Posted September 12, 2018 @James Ainsworth Thanks for all tips. Most things work now but is there a way to unset (for lack of better word) closing status when re-opening the ticket? So that it needs to be set again by the Analyst. Link to comment Share on other sites More sharing options...
Victor Posted September 12, 2018 Share Posted September 12, 2018 2 minutes ago, HHH said: is there a way to unset (for lack of better word) closing status when re-opening the ticket? Yes. You can use the "Update Request - Status" process node and set it to Open Link to comment Share on other sites More sharing options...
HHH Posted September 12, 2018 Share Posted September 12, 2018 @Victor Oops, sorry, I'm using the wrong wordings. What I meant was the closure/resolution category which for us is mandatory. It seems I can set it to something else but no option to clear it Link to comment Share on other sites More sharing options...
Victor Posted September 12, 2018 Share Posted September 12, 2018 @HHH - ah, I understand... well...category can also be set by the process but it might be the case that an analyst needs to review it to make sure is the right one... Link to comment Share on other sites More sharing options...
HHH Posted September 12, 2018 Share Posted September 12, 2018 @Victor Exactly the point. Which is why I want to reset/NULL it so the Analyst will need to choose closure category for the second/subsequent resolves. A second question since I'm working with it right now. The resolve timer is stopped on first resolve. If I start it again as part of the unresolve process will it restart from 0 or resume from where it stopped? Link to comment Share on other sites More sharing options...
Victor Posted September 12, 2018 Share Posted September 12, 2018 9 minutes ago, HHH said: I want to reset/NULL You cannot set a category to NULL I'm afraid, it needs a value... 9 minutes ago, HHH said: The resolve timer is stopped on first resolve. If I start it again It cannot be started again. Once stopped is stopped for good. A timer can be paused, by using the "On-Hold" action. It cannot be paused by other means. But if you stop it, that's it that timer is done. 1 Link to comment Share on other sites More sharing options...
Dan Munns Posted September 12, 2018 Author Share Posted September 12, 2018 @HHH you could set a category of "Requires Category" or similar and have some logic in the BPM to loop back to an analyst task if this hasn't been changed before closure. You could also have some logic causing the request to be placed on-hold 'Waiting customer confirmation' or similar after a human task to complete the request, then after a time automatically set the request to resolved, then closed. I do believe that there should be someway of starting a timer again if a call is reopened. As well as rolling back the big green tick at the end of the sections list and also a way of wiping the resolution if a call is reopened (the original resolution will still be in the timeline after all if it is required) Link to comment Share on other sites More sharing options...
Victor Posted September 12, 2018 Share Posted September 12, 2018 1 hour ago, Dan Munns said: a way of wiping the resolution if a call is reopened Have you tried "Update Request - Resolution Text" and use an empty value for it? Link to comment Share on other sites More sharing options...
Dan Munns Posted September 12, 2018 Author Share Posted September 12, 2018 @Victor nope I meant more as a 'If a call is reopened perform the following actions...' kind of deal, so no extra BPM nodes etc. Would be wonderful to have the option to create a final stage which is only used if the call is reopened but I would have to look into that more, plus the stage showing on all calls would be a pain. Perhaps something the Hornbill Devs could help with? Link to comment Share on other sites More sharing options...
HHH Posted September 13, 2018 Share Posted September 13, 2018 On 8/24/2017 at 4:51 PM, Victor said: @Gary@ADL haven't looked in detail but I did spot the custom expression is using an incorrect value for status... you have typed in "resolved" but this is not the value stored in the database... the correct value for each status is as follows: Request Status: Open - Static Value: status.open Request Status: On-Hold - Static Value: status.onhold Request Status: Resolved - Static Value: status.resolved Request Status: Closed - Static Value: status.closed Request Status: Cancelled - Static Value: status.cancelled Another alternative would be to keep current static value (e.g. resolved) but use "contains" for evaluation rather than an exact match: "==" @VictorHow are sub-statuses treated with regards to this? Is only parent status checked since that's what's in the h_itsm_requests table. Also I'm having trouble getting it to work. If I close the ticket I get a "no gotoIf" error and if I reopen it does not seem to go the right path, it opens but does not follow the intended path. Only expiry works as expected. Attached some screenshots on what I've done so far. This is test thus the 5 min wait for status change. Link to comment Share on other sites More sharing options...
Victor Posted September 13, 2018 Share Posted September 13, 2018 15 hours ago, Dan Munns said: Perhaps something the Hornbill Devs could help with? Not on this one I think... My idea on this would be perhaps creating BP configuration example which can be shared with anyone which has a "Stage" for dealing with the request being reopened. Then whoever needs it can simply copy this stage in their own process... I'll have to think about this one... 1 hour ago, HHH said: How are sub-statuses treated with regards to this? Is only parent status checked since that's what's in the h_itsm_requests table. It really depends on how you build the expression... "Get Request Information - Request Details" node returns both the status and the sub-status so you can use them in your expression: 1 hour ago, HHH said: Also I'm having trouble getting it to work. This issue is that once the status has changed (the "Wait For Status Change" node) the process variables ar not refreshed so it will actually use "old" values, e.g. a previous status, this is why you are getting a "no matching goToIf found" error... So, what you need in the process is a "Get Request Information - Request Details" node after the "Wait For Status Change" node to refresh the values for the process variables... Link to comment Share on other sites More sharing options...
HHH Posted September 13, 2018 Share Posted September 13, 2018 @VictorAdded a "Get Request Information - Request Details" node where you recommended but still "No matching gotoIf found..." I tried both status=status.open and status contains open. Any ideas what I'm missing Link to comment Share on other sites More sharing options...
Victor Posted September 13, 2018 Share Posted September 13, 2018 @HHH - I assume you published the changes in the process? Link to comment Share on other sites More sharing options...
HHH Posted September 13, 2018 Share Posted September 13, 2018 3 minutes ago, Victor said: @HHH - I assume you published the changes in the process? Yes, but question is valid Link to comment Share on other sites More sharing options...
HHH Posted September 13, 2018 Share Posted September 13, 2018 @Victor I found the cause of the continued no gotoif. The Get Request Information - Request Details introduced a new error. I can no longer check for expired in the Decision node since there is a node between the "wait for status change" and the decision. So I get the error immediately when hitting the decision. (Hope this is understandable and sorry for taking so much of your time) Link to comment Share on other sites More sharing options...
Victor Posted September 13, 2018 Share Posted September 13, 2018 20 minutes ago, HHH said: I can no longer check for expired in the Decision node since there is a node between the "wait for status change" and the decision. You're right...Hmm... Let me get back to you on this... Link to comment Share on other sites More sharing options...
HHH Posted September 13, 2018 Share Posted September 13, 2018 @Victor This did it although I'm uncertain which of the OR clauses is the correct one. Link to comment Share on other sites More sharing options...
Victor Posted September 13, 2018 Share Posted September 13, 2018 @HHH - ok, I stand corrected. You don't need the "Get Request Details" node in between (although it should be needed because it needs to refresh the variables, but this is another matter) The expressions, however, the ones checking for the request status, should use the status returned by the "Wait For Status Change" node. As you can see in the screenshot below, the node returns a variable called "new status" which is the status of the request after the process resumed. Using this variable to check for open, resolved or closed will work. To check for expiry just use the "outcome" not "custom expression". 1 Link to comment Share on other sites More sharing options...
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