Jump to content

Auto close and resolve timer


Dan Munns

Recommended Posts

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.  

suspendstatusexpire.png

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

  • 11 months later...

@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

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.

  • Thanks 1
Link to comment
Share on other sites

@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

@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

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.

flow.jpg

closed.jpg

reopened.jpg

Link to comment
Share on other sites

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:

image.png

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...

image.png

Link to comment
Share on other sites

@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

@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".

image.png

  • Thanks 1
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...