Moving issues between 4 technical teams

[Andreas]

Hi!

We have 4 teams working with different parts of our environment. I want it to be possible for these teams to move tickets from one team to another. I want the members of the teams to be able to transfer tickets to all other teams. What would be the smartest way to set this up?

[Nic Brough -Adaptavist-]

JSD does not really expect "team" changes, it works more from "queues".  People are expected to look at queues to help them choose what issue/request to pick up next.

Mostly queues will be defined by urgency (next most likely to breach SLA), but there's nothing to stop you using a team indicator as well as SLAs (or even instead of SLAs if you're not really using them)

You'll need to stamp something on to the issues to show which team it should currently belong to though.  @Grigory Salnikov has suggested components which is the first suggestion I would make (because a component indicates a sub-system, and it's common for that to be useful and have different teams look after different sets, so you could do queues based on "component is a, b or c, then queue/team 1, component is d, e or f, queue/team 2", etc), but you could use any searchable field for it really.

[Andreas]

Ok. I´ll look into using components. But regarding my initial question regarding different teams moving tickets to other teams, that is not possible? I will try to explain more below.

We have a first line/service desk that makes initial work on incidents and then assigns to 2:nd line if needed. We have  2 2:nd line teams, 2:nd line-server and 2:nd line application. If 2:nd line-server team recieves an incident and wants to move it to 2:nd line-application, how should this be handled?

[Nic Brough -Adaptavist-]

Put something on the issue that indicates it is for one of the 2nd line teams, and then define queues for each team.  The teams can change the indicator if they need to swap it to a different team.

[Andreas]

Ok. is it possible to assign to a specific user, or only from one team to another?

[Nic Brough -Adaptavist-]

The assignee is the person considered to be currently responsible for something.  The usual expectation of queues is that an Agent will look at the most urgent thing on their queue and assign it to themselves to say "I've got this one" and then deal with it, although some teams have a lead of some sort who allocates it rather than lets people pick.  You can (and should) do that alongside the team indicator.

[Andreas]

I have looked in to components and that looks like the way to go. Thanks. 

I now wonder if i need to create one project for each team or if it is possible to assign one queue to one specific team? I have tried to read the docs but not found a good answer. I am as you probably understand quite new to the product.

[Nic Brough -Adaptavist-]

Separate projects could work, but you're then asking the users raising your issues to know which of four portals to raise the requests in.

You should move away from the idea of "assigning" things to teams, that does not work.  Define queues that tell people what is next for them to pick up.

[Andreas]

Ok. But can i select which queues are visible to a specific team? I would like the server team to only see their server queue. 

[Nic Brough -Adaptavist-]

You don't.  You should move away from the idea of "assigning" things to teams, that does not work.  Define queues that tell people what is next for them to pick up.

[Andreas]

I´m sorry for not being more detailed. I want to do this for Jira service desk handling mostly incidents.

[Alexey Matveev]

EDITED

[Bastian Stehmann]

Hi @Andreas,

so you have a project for each team and want to move the issues to another project?

You can do that by granting them the Move-Permission and the Create-Issue/Create Attachment Permission in all projects, then they can move issues between the projects.

[Andreas]

Can this be done in Jira service desk?

[Grigory Salnikov]

Hi!

I think the best way is by using Components. Take a look at the following article:

Organizing work with components

[Andreas]

I missed to inform that it is for Jira Service Desk and to handle incidents.