Hi, We have approximately 500 agents over 100 teams across the organization. These teams include many different IT and apps teams, many facilities teams, HR teams, marketing, finance, etc... Essentially anyone who provides a service is a member of a team and some people are on multiple teams. Given the above, I'm wondering the best way to architect a Jira Service Desk implementation to ensure all of the following requirements can be met: * Allow an agent to see all work assigned to one or more teams he is a member of and not clutter up his view with work not related to his area * Send an e-mail to all team members when an issue is assigned to a team he is a member of * Enable any team to see the tickets of any team (except for HR) and to re-assign a ticket to any other team * Enable reporting at team level (e.g., team-level resolution time, SLA, issue counts) * Customer has one place to go to report an issue and see status of an issue * Issue auto-routes to team based on categorization selected by customer * Ability for a multi-task type request to create separate sub-tasks to be worked and closed by different teams (e.g., on a new hire, a task to build a computer is assigned to an IT team whereas a task to clean the office is assigned to a facilities team). It seems from other posts, the two main options are to either create a project per team or create a custom team field and set up multiple queues. Those options seem to meet some but not all requirements. Are there other ways to set this up? add-ons to consider? Is this a reasonable use case for JSD? Thanks!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Multiple teams in Jira Service Desk

Matt Strandberg

Hi,

We have approximately 500 agents over 100 teams across the organization. These teams include many different IT and apps teams, many facilities teams, HR teams, marketing, finance, etc... Essentially anyone who provides a service is a member of a team and some people are on multiple teams.

Given the above, I'm wondering the best way to architect a Jira Service Desk implementation to ensure all of the following requirements can be met:

Allow an agent to see all work assigned to one or more teams he is a member of and not clutter up his view with work not related to his area
Send an e-mail to all team members when an issue is assigned to a team he is a member of
Enable any team to see the tickets of any team (except for HR) and to re-assign a ticket to any other team
Enable reporting at team level (e.g., team-level resolution time, SLA, issue counts)
Customer has one place to go to report an issue and see status of an issue
Issue auto-routes to team based on categorization selected by customer
Ability for a multi-task type request to create separate sub-tasks to be worked and closed by different teams (e.g., on a new hire, a task to build a computer is assigned to an IT team whereas a task to clean the office is assigned to a facilities team).

It seems from other posts, the two main options are to either create a project per team or create a custom team field and set up multiple queues. Those options seem to meet some but not all requirements. Are there other ways to set this up? add-ons to consider? Is this a reasonable use case for JSD?

Thanks!

Accepted answers

All comments

unknown

Hi @Matt Strandberg,

As an Atlassian Consultant, I will try to help you with some points, but I am pretty sure that you are going to need a specialist service and a detailed explanation of your situation to an expert so they can help you. That is a paying service.

Points 1 and 3 are contradictory, need ¡more information to find a solution. Thinking quickly, you probably need Dashboards with filters.

Point 2 must be done via Notification Scheme and workflow postfunctions

Point 4 is already solved by Jira Service Desk, you should define exactly which kind of reporting will be needed.

Point 5, 6 and 7 are already solved by Jira Service Desk portal and automations

I can't help you more than this even if you are more specified because usually, it takes hours to have all the points defined to start working in a solution. I hope that these tips help you to find the solution to your problem.

Matt Strandberg

Hi Cristian,

Thank you for your response. I should clarify that what I'm really looking to understand is what type of team architecture is recommended given that we'd need to solve the requirements I provided. for example: would it be advisable to have a JSD project per team or is there a way all of these teams can co-exist in one project?

Can you elaborate on how #1 and #3 are contradictory? We want an agent to not have to sift through the work of other support areas in order to see work assigned to him and his team (#1) and we want to ensure that should that agent want to, he has the ability to find any issues in the system (#3).

As a consultant, have you worked with a client that has had similar needs?

Thanks!

unknown

Hi again Matt,

I misunderstood point 1 and 3. They aren't contradictory, and yes, we are working in a similar project right now in a completely new instance.

With 100 teams and the possibility of users being in many groups, I think that neither creating 1 project nor 100 projects would be ideal. You can separate projects by product or another category (internal, external, departments, etc) which your organization then can use to split the teams in the different projects, and finally use queues and dashboards.

To improve visibility for users in Jira Service Desk, add-ons like Comala Canvas, Queues for Jira Service Desk, Queue Collapse for Jira Service Desk can improve user experience.

Susan Hauth _Jira Queen_

Hi Matt,

I would definitely recommend that you create a service desk by Team. (E.g. IT, HR, Finance). Agents can be agents for multiple service desks. But this way you can more easily tailor each team's service desk for their request types, notifications, components, etc.

The only drawback is that native Queues will only work By Service Desk. You can get around that with plugins as mentioned above, or simply use a dashboard (not as real time, but still pretty good).

Hope that helps

Susan

Matt Strandberg

Hi Cristian,

Thanks so much for your reply. This has been helpful. In particular, the Queues for Jira Service desk add-on seems like it would help clean up the list of queues.

Thanks,

Matt

Matt Strandberg

Hi Susan,

Thank you for your response and help. We have about 100 teams. Are you suggesting we would create 100 projects or are you suggesting we should bundle them by department (e.g., all of the IT teams as one project, all the HR teams as another, etc..)?

The main drawback to this in my limited understanding is that we would would have limited ability to centrally manage configurations. For example, if we wanted a standard assignment e-mail (that is a custom e-mail template that is the same for all teams), it would need to be built and maintained in each project. Is that understanding accurate? If so, how would you propose it be managed?

Thanks,

Matt

Susan Hauth _Jira Queen_

Hi Matt,

I would recommend bundling by department. At this time configurations for request types, SLAs, automation (all the Service Desk supported stuff) has to be managed per project.

However, Screens, workflows, permissions, notifications can be shared to have some centralization.

Hope that helps

Susan

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk