Assigning to unsupported teams

[will.good]

Hi,

We use an autotask to assign a request to a team where that team does not support the service a request is logged under.

This is handy where we might get something logged incorrectly by the customer or have a request that becomes part of another team's responsibility. You can assign to that team without giving them access to see all requests under that service

Since the Service Manager update, this is no longer possible (we were aware that we were essentially taking advantage of a bug)

I feel this functionality should be restored, if a request is being assigned from a workflow or autotask then it's clearly a purposeful decision to do this and not something you can do by accident from the assign action (as the team doesn't appear if it is not supported)

 

Use case from today, we had a fairly sensitive request logged from an applicant that was logged under our Employee Relations service, which our ER team support. Through investigation, this now needs to be assigned to our Talent team. We cannot make our talent team a supporting team of the ER service due to the sensitivity of some of the requests in there (nor do they need to see the requests that sit in that team) so we need a way to be able to assign the request to the talent team. Pre today we would have just used an autotask to assign this over.

[Victor]

6 minutes ago, will.good said:

We cannot make our talent team a supporting team of the ER service due to the sensitivity of some of the requests in there (nor do they need to see the requests that sit in that team) so we need a way to be able to assign the request to the talent team

Change the service on that request to a service twhich the Talent team supports.

[Victor]

7 minutes ago, will.good said:

I feel this functionality should be restored

As you suspected this was a defect therefore it will not be reintroduced but I am sure we can explore options based on certain use cases. But having this back in the form it existed until now, it won't be happening I'm afraid. 

[Steve Giller]

3 minutes ago, will.good said:

we were aware that we were essentially taking advantage of a bug

4 minutes ago, will.good said:

I feel this functionality should be restored

It's not very common for us to be asked to inject a bug into the code. I can't speak on behalf of the developers but I don't envisage a scenario where that will happen.

If you're using an autotask you can, rather than reassign, raise a linked Request under the correct CI going to the correct team, or under a generic CI for a Service that the required Team supports, you can also raise a linked Request from the Action Bar which will allow you to select the correct Service, CI, and Team.

[HHH]

On 11/07/2024 at 11:20, Victor said:

Change the service on that request to a service twhich the Talent team supports.

@Victor Is it possible to change service of a request? How?

[Victor]

@HHH it can only be achieved via workflow automation. You can incorporate this logic into the request workflow and/or have this run by an auto-task.

 

 

[MacLean Ferguson]

We're also feeling the sting of losing this as a function. For some of our buttons we are currently also changing the service, but many of our buttons needed a verification or one step completed by a less technical team before being reassigned to the initial service. Now we'll need to add tickets back and our service teams will lose the ability to go grab some of those tickets back themselves. 

We've found a workaround for some of the more regular uses for these buttons but it also feels like we're abusing a corner case where we're making new services and retiring them so we have a shared queue to work some tickets without adding clutter to requests. That already is an unpopular solution for us as its muddying some of our tracking. 

For some of our teams we are able to use assign member as a workaround but most of our teams are not used to checking "I'm a Member" and not having the ability to use "or" in our filtering to see all of the tickets that are in your window of responsibility in one page means a lot of member tickets get missed.

I know this was a bug but cross team collaboration without giving access to whole services is a pain point for us already and this is a hit to a lot of our workflows. 

[Victor]

11 hours ago, MacLean Ferguson said:

We've found a workaround for some of the more regular uses for these buttons but it also feels like we're abusing a corner case where we're making new services and retiring them so we have a shared queue to work some tickets without adding clutter to requests. That already is an unpopular solution for us as its muddying some of our tracking. 

@MacLean Ferguson as you mentioned, it was indeed a defect. While we understand that fixing it affects some of our customers' current way of working, I'm afraid we won't be able to revert the change. However, let's see if can find a solution. I would start by exploring why you feel this is necessary. There might be configuration options we can implement to achieve your desired result without bypassing Hornbill's intended logic. Could you please some details about your current process(es) and how the removed functionality was beneficial to you?

[MacLean Ferguson]

@Victor

If there is a better intended way to manage some of this that would be great.

Our biggest use case for this is collaboration without giving users access to full service history. We have a lot of instances where we may need a step of an IT process approved or completed by our Workforce team. With our buttons we could add them in to the ticket to do their work on the ticket with full access to the timeline without adding anyone extra to a service. This could be done by skipping across services but, for a number of our non-IT users, interacting with a ticket more than reading the timeline and leaving a note is pushing the edge of their comfort. Right now they can message IT in teams when their part is done and one of our techs can reassign the ticket themselves. 

Another of our uses is creating holding queues. We have a number of placeholder teams created to hold on to tickets that have long wait times. Some of these are also centralized places to look up the status of work. We use one of these teams to hold all of our Known Error tickets so there is an easy place to investigate all live KEs. We have another that is just for hardware returns for our techs to clear their individual queues to just actionable work while waiting on shipping, it then serves as a queue to check for our receiving team when we get packages in. We could just add all of these teams to each service but the concern is the amount of clutter it adds to our assignment teams.

[JJack]

@Victor updateReqService 'You can incorporate this logic into the request workflow and/or have this run by an auto-task.'
We have found good use for changing a catalog item in a process and starting off a new process. It allows some flexibility into rather cumbersome workflow set-ups. Should be more widely known I think.