I would like this for my company/project. Any updates? 

Progress?

We need this as well.

Simple solution seems to be to remove the auto filter on Queues to Project = "Name" and allow that to just be a working variable.

My organization needs this!  We manage our internal project work and software requests through Jira and have various integrations with Bitbucket and Perforce.  However, as we continue to grow,  we're organizing ourselves in such a way that we want our internal customers to request work through a single portal.  We don't believe they should need to know (or care) which team executes their particular request.  We present them with a menu of service items, they select which item they need and enter in their information.  From there, we route the request type directly to the correct team.  Whether this team is using a plain old Jira software project or another JSD project to track their work would be irrelevant.  The request should be able to "route" directly to the owning team (in our case the Jira project or JSD project of our choosing).  Logically, this means each form or instantiated request type should map directly to an owning team.  Over time, we would update those owners as team's change and processes mature.  From a customer perspective, they are unaware of anything going on behind the scenes, effectively abstracting all of the sausage making from the customer.

It would definitely be nice to be able to integrate multiple (but not necessarily all projects) under one customer portal.

In a large organization, it is common to have multiple teams/area using Jira Service Desk to track tickets in their own Jira project, but from a Customer/User perspective, it is nice to be able to make requests in one portal instead of having to figure out which portal they have to go to for raising tickets.

e.g. Technology Help Desk; Building Facility; Application Support; DBAs; Business Projects; Access management; these teams may all have their own Jira projects setup, so it would be ideal if Customer Portal can be setup to direct users to respective areas/projects to raise tickets that concerns general users (users probably don't need to raise DBA or Business Projects related tickets, so may still require different Customer Portals for certain projects).

Bottom line, I believe ideally Jira Service Desk should be flexible enough to allow multiple customer portals per project as well as multiple projects within each customer portals.

We are a large sales company that has many supporting departments. Our goal with this is to have a single pane of glass where the agent can see all support options available to them. These "shared services" or supporting departments each have their own projects in Jira but they are will receive requests from the sales floor. Right now the sales floor has to pick the correct service desk portal to ask a question. Becuase of this, we have seen zero adoption of the portal and people still relying on email because they say they dod not know which portal is the right one. 

This is important for us for the same reason JIRA Software supports multiple projects in a scrum sprint. Developers can work across projects and support staff can work across projects.

It is vital that support staff be given access to the Service Desk queue list across more than one project. Otherwise Atlassian is basically saying that the entire organisation's support services need to be contained in a single project and you can't use the flexibility of separate projects to associate with different workflows, issue types, etc.

Even a single live updating set of queues with SLA notifications, in addition to the existing per project queues, would be sufficient here.

For our use case it would be #2 or #3.  Our one help desk supports multiple different products in a product suite.  Each of these products are running Agile projects with different sprints, etc.  Some are linked to Confluence site, some are not.  We have 4 service desks tied to 4 different projects.  We would like the ability to have one Service Desk for all, force user to identify product they need help with at time of submission and that put it into a specific product queue, but all our agents can view.  All agents could see the queues for each product and push into backlogs of any of the projects as needed.

{quote}

Hi everyone,
Could you specify the use cases with more details?

1. Is it the same team working on multiple projects? Or multiple teams? What are the projects used for?
2. When does your agent need to refer to both the queues and the dashboards, or even potentially boards or filters?
3. What would you like to achieve by having a service desk working across multiple projects?

Thanks!
The JIRA Service Desk team

{quote}

Use Case Answers:

1. Same team working on multiple projects.  Projects are all related to similar applications / environments but some customers have dedicated JIRA projects as we do a lot more than general support with them.
2. Agents would mostly refer to the one set of Queues that contain issues from multiple projects.
3. One place for Agent's to view ticket queues from so they do not have to have multiple tabs open to multiple different projects.  Current we use a Kanban board but miss out on the nice side menu of the queue system and it just feels clunky for the purpose.

Given that the queue system is currently so integrated with a project, perhaps this could be accomplished with a new "Board" type (i.e. a Support Board option in addition to the familiar Agile and Kanban boards).  These support boards would have the same layout as the Queues within a project but be populated entirely from JQL in the same manner as existing Agile boards are.

Would it be possible for someone on the Atlassian side to provide any type of update on this issue or even issue JSD-1034?

If this isn't something that is going to be considered, can you please let us know? Or perhaps suggest a workaround that could be use?

We too could use this feature.  We have multiple product lines, each running its own JIRA project with different boards.  We want one SD (as we have one Service Desk team answering questions across all products) through which all requests flow and then can be parsed out to various projects as needed if request includes bug, new feature requests, improvements, etc.

In my case, each project is used for support for a different service, and each service has a different set of possible issue types. For example, customers who use our software as an on-premise install of one of our products see a different list of issue/request types than customers who use our platform as SaaS.

I'm running into the same problem.

I have one team that will need to maintain multiple service desks. Although a filter and gadget could work, I need to have a real time solution. 

This brings on the importance of one main service desk queue that links to other projects/queues.

Hi everyone,
Could you specify the use cases with more details?

1. Is it the same team working on multiple projects? Or multiple teams? What are the projects used for?
2. When does your agent need to refer to both the queues and the dashboards, or even potentially boards or filters?
3. What would you like to achieve by having a service desk working across multiple projects?
   Thanks!
   The JIRA Service Desk team

Hi,

1. We have the same team working on multiple projects. One project is for support and other is for development.
2. It is very comfortable for us to use queues, because they are renewed automatically and have a convenient view.
3. We think it would be great to have all issues in one queue and to see the picture in one place.

Thank you! Good luck!

Regards,
Ivan

As a web development agency, we have multiple clients and multiple projects for each client. So Client A might have Project 1, Project 2, Project 3. Different people in the client work on different projects and I need them to log issues against their project.

I don't want to give the client say, 6, different portals - they will never log things in the right place. Ideally I would like a drop down list to be available on the portal screen so that they can choose the project they want to log the issue against.

our team want to set up multiple Service Desk projects so that we can direct different clients to different portal URLs (mainly because we want to have different messages for clients from different time zones or accessing different servers. However our service desk team want to have a single Queue with issues from different service desk projects (not including other JIRA projects).
thanks

Would hope for a couple ways this could be solved:

• While customizing a customer portal, re-use a form found on another portal, including one on that portal (also enables easy copying of existing SD submission forms, yay). Ideally, this would (optionally) then become a shared form like other shared resources in JIRA, so any changes can be inherited by those who are leveraging it.
• When creating a form, be able to select a project and issue type to map it to, bringing in those field contexts and creation screen for fields.

Have a lot of use cases that this would help resolve. Multiple HR teams, multiple IT teams, all with individual projects and permissions, many with Service Desks. Being able to build a basic SD with many common functions would be glorious, but all the options provided by a flexible implementation could be amazing. The new search stuff will help, but not everyone uses search.

Leave it on the admins to manage permissions, build out queues properly, etc.

Hello, I would like to share our use case too.

1. For us it is the same team working on multiple projects. For example a project for the support of our Communardo Products, another one for our project customers and a third one for a separate project. Furthermore we have some additional customer projects, where we also track the custom development. Our first level support takes care of all those support projects and needs to have an overview of all of them.
2. At the moment we use a single board, covering all our support projects, to have all tickets somehow queued and ordered, regardless to which project they belong. It might be, that we would not need a board anymore, if there is a service desk covering multiple projects.
3. Our goal is it to have one spot to support all our customers. All tickets need to be queued in order to do first what needs to be done first!

I agree with jlarmour. In a perfect world I can decide decide which projects are covered by my service desk. This gives us the freedom to grow and change (e.g. evolve a separate first level team for product support only, which would result in an exclusion of the product support project from the existing service desk into a new one).

Hopefully we will see this feature in a near future

Greetings
Stephanie

In reply to your update.

1. We have one team that works in many projects. As the service desk they look after all our various customers that call in for support. Projects are essentially clients for us. So if we have ten clients, they are all calling for support from my team. To have my team swapping between projects to see what came in isn't really feasible. As well monitoring and reporting, sometimes you want to see the company performance as a whole, sometimes you want to split by client.

In a perfect world I would be able to have my technician go to their service desk and I can have various clients/projects turned on and off based on that particular technical assignment, or at least service desks that I can choose draw info from whichever projects. Essentially merging the concepts of dashboard and service desk. Honestly if I could display the service desk features, such as queues on a dashboard that could probably work in many ways too.

2. Right now we do everything via dashboards that show all our clients, and some area's for specific high volume clients. We use filters to create our queues via status and assignee to a degree.

3. I would like to have one cohesive spot for my technicians to look at for what they need to pick up as it comes in. A home page of the service desk if you will. Some of my smaller clients might log two or three tickets a month, they need to show up where my tech's are looking as they come in. The theory of jira right now seems to be that I have multiple service desks for each projects, supporting a software type for instance, the mindset from which Jira originated. I have one service desk, and many clients that fit that umbrella. I have setup dashboards to reflect that, I want to use Jira service desk more, but it's walls of separation are a roadblock.

Hi,

Thanks for giving us the possibility to give you more insights regarding our use cases.

1)
We have 20+ international support teams. Each team does support its local customers in an individual JIRA project (so we have 20+ projects). This has numerous reasons and cannot be changed (and we already turned every stone. ONE reason is the way that customer data is added to a ticket - there is no common way possible).
There is a central team within our HQ that has two responsibilities: 1) to support their local customers and 2) to support the other international support teams in case they run out of ideas. Which means that an international team member creates an Assignment to the HQ team if it needs support from them.
So the challenge is that the HQ support team runs Service Desk to manage its local customers, but cannot use Service Desk to also manage the Assignments coming from other teams (and therefore other projects). Because Service Desk cannot handle more than one project. So issues need to be handled in two separate UI, there is no general prioritization possible, and SLAs cannot be measured for requests coming from the international teams.

2)
See 1). Agent works its queues, but needs to check a Dashboard for the international requests. To get it straight: this is a pain in the a**.

3)
The HQ team works on about 800 tickets/month coming from HQ customers, plus about 100 Assignments/month coming from international support teams. Currently, there is no proper handling possible due to the need to work in two separate UI. We need one Service Desk for the HQ team where ALL requests (local customers plus Assignments from international teams) can be handled via queues and are measured against the same set of SLA.

Hope this helps. Please let me know if you have any further questions.

Best Regards,

Thomas

...and this is really causing some pain as I absolutely need to integrate the international service teams. They all work with their own projects and issue types won't do the trick. However, for projects that are entirely new, I now always suggest to use one project only and to go for issue types. But still I can't have my team working with x Service Desks at a time because.

"not asking for multiple projects in the Customer Portal front end but for multiple projects in the Service Desk back end." - cannot agree more