Jump to content

Suspend to work on 24 hr clock rather than WTC


Recommended Posts

I have a business process workflow where we have put a suspend of 1 minute at the start. This is because the ticket is created by an API call from a script, and there are 2 calls in the script (the 2nd updates custom variables within the ticket), so we want to give it time for both to execute. The problem is that the suspend seems to wait according to the working time calendar. So, if I submit a request at 1730 it doesn't release the suspend until 09:01, which I think is because of how the WTC is set up. While we do not expect our staff to work 24x7 we do expect that Hornbill will create tickets when they are raised, so want the suspend to be for 1 minute not 1 minute within service hours. Make sense ? Is there a way to do this ? Setting up a loop until a mandatory custom field has a value is the best I can think of.

  • Like 1
Link to comment
Share on other sites

I would suggest moving the delay into the script.

That's not really what Suspend nodes are designed for, and quite aside from it honouring the WTC (which I don't expect to change) you are inviting other potential issues by using the node to "stick a delay in"

Link to comment
Share on other sites

How does that work, Steve ? To do that I think I would need the script to do everything in one call. The original script was provided by Hornbill so I assume there's a reason it does it in two calls rather than one. 

Link to comment
Share on other sites

The way of doing this that I think we may have to adopt (unless someone can suggest something better) is to set up a decision loop that keeps interogating the request until the custom variable set in the 2nd call has been populated. 

Link to comment
Share on other sites

@RIchard Horton Depending on how long that takes you may hit a hard limit - looping is not a "good thing" especially in a Cloud product, and that kind of loop normally takes microseconds to action.

6 hours ago, RIchard Horton said:

While we do not expect our staff to work 24x7 we do expect that Hornbill will create tickets when they are raised, so want the suspend to be for 1 minute not 1 minute within service hours.

I'm not sure why there is an issue here. Regardless of the delay in unsuspending, the Request creation time does not change. If no actions are being taken on the Request out of hours then the Custom Field updates not taking place until you reach working hours shouldn't affect things?

The other option is that, unless everything about the Request completely relies on those Custom Fields, you can do "other stuff" before updating them - assigning a Priority and/or SLA, passing it to a Team/Owner, sending the Customer an acknowledgement email etc. These all take time that should give plenty of opportunity for both API calls to complete.

Link to comment
Share on other sites

Thanks Steve. Unfortunately information we are picking up from the 2nd call is key to the next steps we want to perform. As you say, what we're wanting to do is simply instigate a short pause to allow the 2nd call to complete (I've now understood that the 2nd call is necessary because custom fields are in a separate table so you need the first call to complete to give you the relevant linkage to update them). You are right that in theory no one is working so why does it matter. However we don't work in an "everyone clocks off at 5" environment and it is frustrating if you are working beyond the standard service day defined in the WTC not to be able to work on requests that you know have come through. 

Link to comment
Share on other sites

@RIchard Horton Without a deep dive into the process it's diffcult to be sure of the best way forward.

On 5/13/2022 at 11:26 AM, RIchard Horton said:

the ticket is created by an API call from a script, and there are 2 calls in the script

On first read I was assuming that there are 2 API calls - one to raise the Request, then one to update the Custom Fields, however

59 minutes ago, RIchard Horton said:

information we are picking up from the 2nd call is key to the next steps we want to perform

suggests that there are 2 separate Requests.

How to proceed with one Request ensuring that the Custom Fields have been updated may well take a different path to two Requests with the first waiting for the second to be raised and populated.

Link to comment
Share on other sites

Thanks Steve. It's the first scenario. The form input needs some processing to determine the customer. I think I have found a way to deal with this combining your comment above with my looping idea. What I have done is a decision node that loops back if the custom field is not set. Within the loop it does a write to the timeline and then a get request. I have tested it and it only goes round the loop twice - the activity in the first loop is sufficient to allow the custom fields to have been set. 

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
 Share

×
×
  • Create New...