Closure category issues

[lomixture]

 

Morning all

I have had the above issues raised to me about 9x in recent weeks, since an update I believe.

We have no use for closure categories in our area of business, but another area uses a handful and so we don't have the option to turn the closure category feature off. Therefore, we build our processes to auto assign a closure category and allow our staff to resolve as usual without having to do this step.

However, since a recent update, the above keeps popping up, but it is not showing the staff an option to choose, even though we have two options to choose from in the tree (below)

 

Therefore, our staff are weirdly having to leave the request to get rid of it, because upon reentering the same request the requirement to choose a closure category has disappeared.

Any ideas on how to resolve this, or remove it for our Services but not others?

[Steve Giller]

Which of the above categories are you auto-assigning, and where in the Business Process are you doing this?

 

[lomixture]

@Steve Giller

Its a long time since I did this build, 5+ years, but we have a general business process each for SR's and IN's, so everything from our area feeds into those and there are branches within if it specialises for some reason.

Up until a few weeks ago, this requirement for a closure category never showed in Facilities, but always showed in ...

 

(stopped typing because I've just realised all the issues have come from Finance not Facilities, and I may have forgotten to build it in on their newer process! will update you if I find the problem!)

[lomixture]

@Steve Giller - it's definitely in the build, I just checked it.

So to me, it seems like it is failing to recognise there is a pre-detemind action there but if they refresh it the business process catches up and sets it for them.

[Steve Giller]

On this, I would set the Resolution/Closure category well before reaching any point at which you can Resolve the Request.

Although referred to as a Closure Category, as you can see, enforcing this also applies to the Resolution action.

[lomixture]

Where would you suggest we put the node, to negate our staff having to click into it but the BP recording it?

[Steve Giller]

As far as I'm aware anywhere before attempting to resolve is fine - you could arguably do it right at the start.

[DRiley]

We were impacted by this update too. One of our teams doesn't use resolution/closure categories either and having a category level set down to the maximum levels in the service configuration provided a solution.

Hornbill insist that something has been addressed so that things work "correctly" in relation to this setting. However, if you refresh you browser the mandatory message disappears. That new behaviour Vs a previously logical (and reliable) approach to the situation makes the "fix" hard to stomach. It's as if someone saw the description of the application setting and took offence. One might think it was easier to caveat the description of the setting. The motivation for this "fix" is a little baffling.

The lack of an alternative to support the preferences of different business areas on the platform, or any commitment to fill the gap in capability which has been created, adds more frustration to the situation. It's not often I throw my toys out of the pram, but this one has created back-lash for us too.... and on a side note, I'm still waiting for an update on my escalation in relation to this.

In my opinion, setting the resolution category before the ticket is resolved is not the right approach. Secondly, what are we meant to set it as, just a generic one? I'll have to review my category-related reports to exclude such a value as its essentially acting as a placeholder for those teams where the category isn't of any use.

Dan

[lomixture]

I must agree with you @DRiley, it does seem absurd that this simple option can't be service specific.

[Berto2002]

16 hours ago, DRiley said:

Secondly, what are we meant to set it as, just a generic one?

Are you trying to set a closure category 'automatically in the BPM (i.e. without the users having to manually select it) but that closure category will not always be the same, it will be dependent upon the actions taken or type of request?

You can use Decision nodes in the BPM to separate the workflow into multiple streams, either based on the fields of the Request itself (like the service) or based on the results of Human Task outcomes, and each of those paths can then be given a serial collection of nodes to:

• Update Resolution; with variable text derived from a Human Task or manual text
• Update Closure Category
• Email/Notify the stakeholders
• Set the status to Resolved or even closed

In short, your users never have to use the Resolution Action area of the Request (in which the category needs to be set) because the Resolution Text and Category are provided in the BPM. The number of options for categories automatically selected is only limited by the number of paths you provide in the BPM.

Does this help?