• 10
    • 12
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Jira Service Management Data Center. Using Jira Service Management Cloud? See the corresponding suggestion.

      As an administrator of Jira Service Management, I'd like to enable more than one project to be visible in Service Desk itself. My team of support specialists now need to work with more than one Service Desk plus Jira dashboards which makes work inefficient. It also makes work load intransparent.

      FYI: This is not a duplicate of https://jira.atlassian.com/browse/JSD-52 as I am not asking for multiple projects in the Customer Portal front end but for multiple projects in the Service Desk back end.

      Update as of 6 October 2015

      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

            [JSDSERVER-2116] n:1 relation for Service Desk: multiple projects, one Service Desk

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

            Sarah Linscott added a comment - I would like this for my company/project. Any updates? 

            JD added a comment -

            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.

            JD added a comment - 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.

            Progess on this??

            Ben Weisman added a comment - Progess on this??

            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.

             

            Christopher Parsons added a comment - 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.

            Wallace Wong added a comment - 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.

            Justin Snyder added a comment - - edited

            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. 

             

            Justin Snyder added a comment - - edited 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.

            Aristedes Maniatis added a comment - 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.

            Leslyn McNabb added a comment - 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.

            Simon Peters (L) added a comment - - edited

            {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.

            Simon Peters (L) added a comment - - edited {quote} Hi everyone, Could you specify the use cases with more details? Is it the same team working on multiple projects? Or multiple teams? What are the projects used for? When does your agent need to refer to both the queues and the dashboards, or even potentially boards or filters? 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: 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. Agents would mostly refer to the one set of Queues that contain issues from multiple projects. 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?

            Megan Makowiecka added a comment - 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?

              Unassigned Unassigned
              51fe7a47c6b4 Martin-Christian Cordes
              Votes:
              157 Vote for this issue
              Watchers:
              92 Start watching this issue

                Created:
                Updated: