Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-52

As an admin I want to have multiple projects in one Customer Portal

    • 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 Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      Please enhance Service Desk so that a customer portal can display multiple projects in the one portal.

      -------------------------------------------------------------------------------------------------------------------
      Fixed: Introduction of the Help Center

          Form Name

            [JSDSERVER-52] As an admin I want to have multiple projects in one Customer Portal

            Hi,
            I opened https://jira.atlassian.com/browse/JSD-2116 as I don't see any progress in this issue with regards to what you guys are discussing and which is also highly important to me.
            Feel free to vote, please!
            Cheers, Martin.

            Martin-Christian Cordes added a comment - Hi, I opened https://jira.atlassian.com/browse/JSD-2116 as I don't see any progress in this issue with regards to what you guys are discussing and which is also highly important to me. Feel free to vote, please! Cheers, Martin.

            AnneD added a comment -

            Is this going to be part of the Jira Service Desk improvements road map?

            AnneD added a comment - Is this going to be part of the Jira Service Desk improvements road map?

            IndieA added a comment -

            @jason
            This looks like an excellent suggestion, but I wonder if the Atlassian guys will notice it... (They have closed the issue after all.)
            I'm not sure what the proper procedure for this is, but seeing as you can't reopen this issue I would suggest creating a new one.

            IndieA added a comment - @jason This looks like an excellent suggestion, but I wonder if the Atlassian guys will notice it... (They have closed the issue after all.) I'm not sure what the proper procedure for this is, but seeing as you can't reopen this issue I would suggest creating a new one.

            Thinking on this a bit more... I guess they could resolve some of these issues by forcing you to bind a JIRA Project up to one and only one service desk – i.e. it would be a pick list and free form JQL wouldn't be used as with Agile boards. When setting up a new service desk you would only be able to bind it to projects which weren't already allocated against a different service desk. A given project wouldn't be able to show up under more than one service desk.

            Jason Orlando [Dow Jones] added a comment - Thinking on this a bit more... I guess they could resolve some of these issues by forcing you to bind a JIRA Project up to one and only one service desk – i.e. it would be a pick list and free form JQL wouldn't be used as with Agile boards. When setting up a new service desk you would only be able to bind it to projects which weren't already allocated against a different service desk. A given project wouldn't be able to show up under more than one service desk.

            @elvir
            This is supposition on my part, but i don't expect that part to change. Recall how JSD calculates the SLA's for tickets. I think that by binding the Service desk to be 1 to 1 with a project, they avoid any issues with a particular ticket being held against 2 different SLAs (because it matched 2 different 'service desk' filters, assuming it was possible to define a service desk with a JQL query similar to agile boards). Also recall for performance reasons those SLA's are calculated and then cached in the ticket as a field. So assuming a given ticket matched the filter for multiple service desks, how would that work? they'd have to implement something pretty arbitrary and confusing like present a different SLA # depending on which context the user was viewing the ticket? (from service desk portal 1 or service desk portal 2?) What if they are simply doing a normal JQL search (under issues->search for issues) Which should be shown? (all?)

            Due to some fairly tough design questions such as these, i don't expect we'd ever see a JQL based definition of service desks. Recognizing this was the likely scenario – my team was merely hoping for the ability to drive end users at a single point of entry(which could then branch to the many different service desks we have set up in JIRA), something that the help center seems to at least partially resolve.

            I think this feature is a step in the right direction.

            Jason Orlando [Dow Jones] added a comment - - edited @elvir This is supposition on my part, but i don't expect that part to change. Recall how JSD calculates the SLA's for tickets. I think that by binding the Service desk to be 1 to 1 with a project, they avoid any issues with a particular ticket being held against 2 different SLAs (because it matched 2 different 'service desk' filters, assuming it was possible to define a service desk with a JQL query similar to agile boards). Also recall for performance reasons those SLA's are calculated and then cached in the ticket as a field. So assuming a given ticket matched the filter for multiple service desks, how would that work? they'd have to implement something pretty arbitrary and confusing like present a different SLA # depending on which context the user was viewing the ticket? (from service desk portal 1 or service desk portal 2?) What if they are simply doing a normal JQL search (under issues->search for issues) Which should be shown? (all?) Due to some fairly tough design questions such as these, i don't expect we'd ever see a JQL based definition of service desks. Recognizing this was the likely scenario – my team was merely hoping for the ability to drive end users at a single point of entry(which could then branch to the many different service desks we have set up in JIRA), something that the help center seems to at least partially resolve. I think this feature is a step in the right direction.

            EL added a comment -

            @jason
            Thank you for the link.

            What I understood is that the global help center is kinda a list of all your service desks. How ever each service desk is linked by a 1:1 relation to a unique JIRA project.
            Meaning that for e. .g. You will not be able to display issue from service desk B (project B) in the queues of service desk A ( project A).

            Cheer up

            EL added a comment - @jason Thank you for the link. What I understood is that the global help center is kinda a list of all your service desks. How ever each service desk is linked by a 1:1 relation to a unique JIRA project. Meaning that for e. .g. You will not be able to display issue from service desk B (project B) in the queues of service desk A ( project A). Cheer up

            @Caesar: https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+2.5+Release+Notes#JIRAServiceDesk2.5ReleaseNotes-What'snew

            Correct me if i'm wrong, but it looks to me like that feature (global help center) was released on in JSD 2.5, which was just released on June 15th, just one day before you made your comment.

            Jason Orlando [Dow Jones] added a comment - @Caesar: https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+2.5+Release+Notes#JIRAServiceDesk2.5ReleaseNotes-What'snew Correct me if i'm wrong, but it looks to me like that feature (global help center) was released on in JSD 2.5, which was just released on June 15th, just one day before you made your comment.

            Separate service desks per customer is one option, but you should be able to do different SLAs per customer if you track customer as a field. If your service desk portals will be drastically different per customer, you may want to consider separate portals.

            Dashboards can be used to offer very similar views to the service desk field using JQL queries, but unlike the service desk view, can span projects, so that might work well for your circumstance.

            Casey Feskens added a comment - Separate service desks per customer is one option, but you should be able to do different SLAs per customer if you track customer as a field. If your service desk portals will be drastically different per customer, you may want to consider separate portals. Dashboards can be used to offer very similar views to the service desk field using JQL queries, but unlike the service desk view, can span projects, so that might work well for your circumstance.

            Hmm I think than we can't use ServiceDesk for our company.
            We have around 80 Agents, splitted in several teams. Every team (3-7 members) have around 4 up to 10 different customers. Sometimes every customer have a different SLA on specific request types which also depends on the customer.
            For my understanding it is better to make an own Service Desk for every customer?

            We can't tell the team that they should switch their ServiceDesk to get all the queues.

            We have to think about how to manage all customers within one Project (we have a role-based permission set).

            Andre Lehmann added a comment - Hmm I think than we can't use ServiceDesk for our company. We have around 80 Agents, splitted in several teams. Every team (3-7 members) have around 4 up to 10 different customers. Sometimes every customer have a different SLA on specific request types which also depends on the customer. For my understanding it is better to make an own Service Desk for every customer? We can't tell the team that they should switch their ServiceDesk to get all the queues. We have to think about how to manage all customers within one Project (we have a role-based permission set).

            Mate, I reckon you need to further investigate the features of JIRA and Service Desk, with the enabling of HELP CENTER, you can put all the Service Desk Portal in one interface, elvir is correct, you will use the dashboard to view all the issues created in service desk which is the Interface entry for all of your agents. I did this setup in our company and it looks fine. The difficulty is the access and permission for all of the projects, I know you can set it up by role based but there is a lot of works attached to it. I suggest that you get a product demo from them of one of the re seller, I suggest consult with Service Rocket.

            Caesar Sulapat added a comment - Mate, I reckon you need to further investigate the features of JIRA and Service Desk, with the enabling of HELP CENTER, you can put all the Service Desk Portal in one interface, elvir is correct, you will use the dashboard to view all the issues created in service desk which is the Interface entry for all of your agents. I did this setup in our company and it looks fine. The difficulty is the access and permission for all of the projects, I know you can set it up by role based but there is a lot of works attached to it. I suggest that you get a product demo from them of one of the re seller, I suggest consult with Service Rocket.

            So I really cant have multiple Jira-Projects within one single ServiceDesk?

            Andre Lehmann added a comment - So I really cant have multiple Jira-Projects within one single ServiceDesk?

            EL added a comment -

            As you can see here https://confluence.atlassian.com/display/SERVICEDESK/How+JIRA+and+JIRA+Service+Desk+Work+Together
            There is a 1 : 1 relation between Jira project and service desk.

            You are welcome.

            EL added a comment - As you can see here https://confluence.atlassian.com/display/SERVICEDESK/How+JIRA+and+JIRA+Service+Desk+Work+Together There is a 1 : 1 relation between Jira project and service desk. You are welcome.

            Oh, that is a shame. Thank you for your help.

            Jamie Dunbar added a comment - Oh, that is a shame. Thank you for your help.

            EL added a comment -

            Oh I see
            That's not possible I think. On the service desk view, agents can only see tickets from the current service desk.
            A walkaround would be to use a dashboard with a a cross project filter but I agree it is not perfect.

            EL added a comment - Oh I see That's not possible I think. On the service desk view, agents can only see tickets from the current service desk. A walkaround would be to use a dashboard with a a cross project filter but I agree it is not perfect.

            I want the all agents to be able to see all tickets (from email or portal) in their queues. Assuming they are logged into servicedesk 1 (treated as the main core service desk) they can also see service desk 2 as well.

            Jamie Dunbar added a comment - I want the all agents to be able to see all tickets (from email or portal) in their queues. Assuming they are logged into servicedesk 1 (treated as the main core service desk) they can also see service desk 2 as well.

            EL added a comment -

            When you say viewable across service desks, do you mean on a dashboard view, or filter result view ? based on your screenshot you got the browse permission on the this issue

            EL added a comment - When you say viewable across service desks, do you mean on a dashboard view, or filter result view ? based on your screenshot you got the browse permission on the this issue

            OK, both agents are on both service desks.

            Currently the issues aren't viewable across service desk boundaries.

            This is the result of the permissions helper idea

            http://www.awesomescreenshot.com/image/313383/5fca9ab127ab2d342dbfd29cd7dceabc

            Jamie Dunbar added a comment - OK, both agents are on both service desks. Currently the issues aren't viewable across service desk boundaries. This is the result of the permissions helper idea http://www.awesomescreenshot.com/image/313383/5fca9ab127ab2d342dbfd29cd7dceabc

            EL added a comment -

            How about you open the issue the agent can not browse and use the "permission helper" ?

            EL added a comment - How about you open the issue the agent can not browse and use the "permission helper" ?

            So far I have the same two agents in both service desks but cannot see tickets across projects. Is there something else I can check? Thank you for your help, FYI.

            Jamie Dunbar added a comment - So far I have the same two agents in both service desks but cannot see tickets across projects. Is there something else I can check? Thank you for your help, FYI.

            EL added a comment -

            @jamie Dunbar

            Actually yes, go to your 2nd service desk project (People Tab) and add agents you need. You can also assign a particular group to the role "agents" for each jira service desk project

            EL added a comment - @jamie Dunbar Actually yes, go to your 2nd service desk project (People Tab) and add agents you need. You can also assign a particular group to the role "agents" for each jira service desk project

            I am struggling to get this to work too. I have service-desk-agents to whom I have granted "Browse Project" permissions globally, however, they only see issues within a single service desk. These agents need to work across many desks. Is this still possible?

            Jamie Dunbar added a comment - I am struggling to get this to work too. I have service-desk-agents to whom I have granted "Browse Project" permissions globally, however, they only see issues within a single service desk. These agents need to work across many desks. Is this still possible?

            Thanks for the detailed reply Lee, that's incredibly helpful.
            I do agree that some more direct control over the the portal would be incredibly handy.
            I feel like I'm wrestling with Service Desk to do what I want at the moment. =/

            Gregorio Luiz Gomez added a comment - Thanks for the detailed reply Lee, that's incredibly helpful. I do agree that some more direct control over the the portal would be incredibly handy. I feel like I'm wrestling with Service Desk to do what I want at the moment. =/

            Lee Rossi added a comment -

            Mostly a combination of user permissions within Jira and luck

            Default user group for all staff is User

            Projects 1-4 have individual service desks attached for internal requests of different types (tech, design, web etc). They are assigned the defualt permission scheme that allows User group members to Browse Projects.

            Project 5 has a new user group setup, and a custom permission scheme that removes the User group from Browse Projects and replaces it with just the project 5 group (and admins)

            This means the portal for 'User' shows just the first 4 unless they are also a member of the project 5 group.

            We could also isolate project 5 entirely by bringing them out of the 'User' group.

            It's all fairly straightforward to setup, you just need to dig into Jira at a project level to then support the front end that Service Desk provides. I'd personally love to see some more direct control over the portal (especially branding like the Service Desk pages can have) within the service desk backend, but hopefully that's something we'll see down the line!

            Lee Rossi added a comment - Mostly a combination of user permissions within Jira and luck Default user group for all staff is User Projects 1-4 have individual service desks attached for internal requests of different types (tech, design, web etc). They are assigned the defualt permission scheme that allows User group members to Browse Projects. Project 5 has a new user group setup, and a custom permission scheme that removes the User group from Browse Projects and replaces it with just the project 5 group (and admins) This means the portal for 'User' shows just the first 4 unless they are also a member of the project 5 group. We could also isolate project 5 entirely by bringing them out of the 'User' group. It's all fairly straightforward to setup, you just need to dig into Jira at a project level to then support the front end that Service Desk provides. I'd personally love to see some more direct control over the portal (especially branding like the Service Desk pages can have) within the service desk backend, but hopefully that's something we'll see down the line!

            @Lee Rossi, how did you achieve what you have described? Show me your ways! =)

            Gregorio Luiz Gomez added a comment - @Lee Rossi, how did you achieve what you have described? Show me your ways! =)

            Lee Rossi added a comment -

            The setup I currently use has 5 service desks each connected to individual projects (I think you can only have one per project?)

            The portal page by default displays 4 of these to all of our internal staff, with the 5th only visible to certain teams as it's only applicable to their use.

            Does that make sense?

            Lee Rossi added a comment - The setup I currently use has 5 service desks each connected to individual projects (I think you can only have one per project?) The portal page by default displays 4 of these to all of our internal staff, with the 5th only visible to certain teams as it's only applicable to their use. Does that make sense?

            ah... I see that I´m misunderstanding this Issue. This only solves half of what I want.
            What I would also like to see is one Agent Portal for multiple Projects.
            Do you know if there is an Feature Request for that?

            Sandra Axelsdóttir [Tempo] added a comment - ah... I see that I´m misunderstanding this Issue. This only solves half of what I want. What I would also like to see is one Agent Portal for multiple Projects. Do you know if there is an Feature Request for that?

            Lee Rossi added a comment -

            The portal by default seems to pick up all service desks created within your Jira installation (you can hide them from the portal by tweaking the browse projects permission if needed) so you shouldn't need to do anything to add it

            Lee Rossi added a comment - The portal by default seems to pick up all service desks created within your Jira installation (you can hide them from the portal by tweaking the browse projects permission if needed) so you shouldn't need to do anything to add it

            I can not find out how to use this feature. I was just installing the latest version of Service Desk and when I create a new Service Desk I can only choose from to create one from one JIRA Project, but not link multiple Projects to the Service Desk.
            Can you please add a link to the documentation for this?

            Sandra Axelsdóttir [Tempo] added a comment - I can not find out how to use this feature. I was just installing the latest version of Service Desk and when I create a new Service Desk I can only choose from to create one from one JIRA Project, but not link multiple Projects to the Service Desk. Can you please add a link to the documentation for this?

            Hi guys, thank you for your patient. This feature is now available with Service Desk 2.0 release.

            Joseph Huynh (Inactive) added a comment - Hi guys, thank you for your patient. This feature is now available with Service Desk 2.0 release.

            John Crea added a comment -

            Awesome ... do you have any indicative milestones set?

            John Crea added a comment - Awesome ... do you have any indicative milestones set?

            shihab added a comment -

            Thanks for your feedback!

            Sorry for the silence on this particular suggestion - it is on our roadmap.

            Our plan is to provide end users / customers with a single landing page. From this page they will be able to navigate to individual project / service desk portals they have access to see. For example, you might have an "IT Service Desk" and a "HR Service Desk".

            Longer term we will be looking to provide the ability to combine request types from multiple service desks.

            shihab added a comment - Thanks for your feedback! Sorry for the silence on this particular suggestion - it is on our roadmap. Our plan is to provide end users / customers with a single landing page. From this page they will be able to navigate to individual project / service desk portals they have access to see. For example, you might have an "IT Service Desk" and a "HR Service Desk". Longer term we will be looking to provide the ability to combine request types from multiple service desks.

            My guess would be that some architecture decision was made and so undoing it at this point would be really difficult. It's a shame more user research wasn't done on this topic because now my org is going with the Microsoft version of the product.

            Deleted Account (Inactive) added a comment - My guess would be that some architecture decision was made and so undoing it at this point would be really difficult. It's a shame more user research wasn't done on this topic because now my org is going with the Microsoft version of the product.

            It amazes me how little feedback Atlassian is giving on this issue...None what so ever

            Vilhelm Bergsveinsson added a comment - It amazes me how little feedback Atlassian is giving on this issue...None what so ever

            Any update on this feature in JSD

            balaji dinoct added a comment - Any update on this feature in JSD

            Antonio added a comment -

            Me too!

            Antonio added a comment - Me too!

            Same here, really need this feature in order to extend the evaluation of the product.

            Danny Verkade added a comment - Same here, really need this feature in order to extend the evaluation of the product.

            Antonio added a comment -

            do you plan to implement this improve? I think, it's really important functionality

            Antonio added a comment - do you plan to implement this improve? I think, it's really important functionality

            Vilhelm Bergsveinsson added a comment - - edited

            The Service Desk looks fantastic and I can easily see my self using it at my company....IF and only IF the problem with one to many relationship is solved. Until then I have no use for it so please do something about it. I´m sure that there are many company´s postponing the installation of Service Desk because of this issue.

            Vilhelm Bergsveinsson added a comment - - edited The Service Desk looks fantastic and I can easily see my self using it at my company.... IF and only IF the problem with one to many relationship is solved. Until then I have no use for it so please do something about it. I´m sure that there are many company´s postponing the installation of Service Desk because of this issue.

            jasonsmith, just thought I'd let you know a (sort-of) workaround I have found for this problem.

            My experience is that if you have multiple ServiceDesks configured, one for each project that issues may be moved in to, as long as they are configured the same way the ServiceDesk tickets will stay visible. A few caveats to be aware of (last time I did this):

            • The user will only ever see tickets for the ServiceDesk they are currently looking at. To see moved tickets they will have to navigate to the respective ServiceDesk. This is the biggest problem so far.
            • The ServiceDesk 'request type key' needs to be identical between ServiceDesks. You can see this in the URL when looking at a ticket. It is a value stored against the issue, but is hidden and not editable. It also seems to be generated automatically based on the request type's name. If you ensure your request types are created in each ServiceDesk in the exact same way this shouldn't be a problem.

            How that info is useful, hopefully a lot of these problems will be fixed soon!

            Andrew Ardill added a comment - jasonsmith , just thought I'd let you know a (sort-of) workaround I have found for this problem. My experience is that if you have multiple ServiceDesks configured, one for each project that issues may be moved in to, as long as they are configured the same way the ServiceDesk tickets will stay visible. A few caveats to be aware of (last time I did this): The user will only ever see tickets for the ServiceDesk they are currently looking at. To see moved tickets they will have to navigate to the respective ServiceDesk. This is the biggest problem so far. The ServiceDesk 'request type key' needs to be identical between ServiceDesks. You can see this in the URL when looking at a ticket. It is a value stored against the issue, but is hidden and not editable. It also seems to be generated automatically based on the request type's name. If you ensure your request types are created in each ServiceDesk in the exact same way this shouldn't be a problem. How that info is useful, hopefully a lot of these problems will be fixed soon!

            I just thought I'd leave a note to the product managers at Atlassian that our org's decision makers decided that the inability for a user to continue to see an issue in "My Requests" after it has moved projects was a dealbreaker. We don't want to manage projects indefinitely within the "Help desk" project, and the workarounds that come to mind are unpalatable.

            Deleted Account (Inactive) added a comment - I just thought I'd leave a note to the product managers at Atlassian that our org's decision makers decided that the inability for a user to continue to see an issue in "My Requests" after it has moved projects was a dealbreaker. We don't want to manage projects indefinitely within the "Help desk" project, and the workarounds that come to mind are unpalatable.

            ITSupport added a comment -

            Hello,

            we would propose additional request. Along multiple projects for Service Desk we would like additional crucial feature.

            JIRA issues should contain separate Service Desk Ticket Key field. Customer is not informed if error is caused within another project as Issue key has been changed. Basically, we would like to have 1 to many relationship between Service Desk and JIRA Issues on one or more JIRA Projects.

            Customer Ticket Key Number should not be changed but ticket Key could be changed to another project. This feature behavior is crucial for our company.

            ITSupport added a comment - Hello, we would propose additional request. Along multiple projects for Service Desk we would like additional crucial feature. JIRA issues should contain separate Service Desk Ticket Key field. Customer is not informed if error is caused within another project as Issue key has been changed. Basically, we would like to have 1 to many relationship between Service Desk and JIRA Issues on one or more JIRA Projects. Customer Ticket Key Number should not be changed but ticket Key could be changed to another project. This feature behavior is crucial for our company.

            EL added a comment -

            This is a must have. We are planning to purchase JSD if you could include this feature

            EL added a comment - This is a must have. We are planning to purchase JSD if you could include this feature

            I wonder if this is the kind of thing a 3rd party plugin could be developed for?

            Sean Semone added a comment - I wonder if this is the kind of thing a 3rd party plugin could be developed for?

            Hi there,
            We would really love to have JIRA Service Desk linked to multiple projects. We cannot use Service Desk without this functionality.

            Christopher Hut added a comment - Hi there, We would really love to have JIRA Service Desk linked to multiple projects. We cannot use Service Desk without this functionality.

            Hi,
            could you please let us know in which quarter/release this feature will be implemented?
            Thanks

            summitmedia-uk added a comment - Hi, could you please let us know in which quarter/release this feature will be implemented? Thanks

            We would really love to have JIRA Service Desk linked to multiple projects. We probably won't use Service Desk without this functionality.

            Andrew Rampling added a comment - We would really love to have JIRA Service Desk linked to multiple projects. We probably won't use Service Desk without this functionality.

            Sean Cull added a comment -

            Sorry, correction, it is THE highest voted issue not completed

            Sean Cull added a comment - Sorry, correction, it is THE highest voted issue not completed

            Sean Cull added a comment -

            How can this 3rd highest ranked issue ( by votes ) be minor ?

            Sean Cull added a comment - How can this 3rd highest ranked issue ( by votes ) be minor ?

            At the unveil at Atlassian summit 2013 I immediately recognized and raised this issue to the project lead for SD. We have just now purchased this product and are now trying to figure out how best to configure it in the short term, with hopes that this functionality will be added in the future.

            Our needs for this product are:
            single point of entry for customers (1 customer portal)
            support tickets get created in the appropriate JIRA project based on a rule
            support teams can view queues which contain only their support tickets
            customer portal supports a hierarchy (so that the initial options are high level, similar to a phone tree)

            Our IT teams support hundreds of different applications, and we don't expect users to know which applications are supported by which teams. This should be a simple and seamless experience for the user.

            Our JIRA projects are actually broken down already by teams (100+ projects). So having 100 teams all shoving support tickets into a single bucket will be chaos – we need the ability to auto route the tickets created by a unified customer portal to the appropriate JIRA projects. A hierarchy for the customer portal is needed so that we don't have 1000 things to scroll through when the user visits the unified service desk. (we agree with your presenter at summit, if we make it complicated for users, they will go around this process instead of going through it)

            With regards to the unified customer portal, we would also like to be able to configure which confluence spaces (kb articles) get hit at different levels. It may make sense to (as atlassian reps mention in this thread) be able to set up a master customer portal, and inside it, teams set up their own service desks, with links to their own confluence spaces – This setup is probably fine as long as we can make it invisible to the customer. They should see only one service desk in the drop down.

            Jason Orlando [Dow Jones] added a comment - - edited At the unveil at Atlassian summit 2013 I immediately recognized and raised this issue to the project lead for SD. We have just now purchased this product and are now trying to figure out how best to configure it in the short term, with hopes that this functionality will be added in the future. Our needs for this product are: single point of entry for customers (1 customer portal) support tickets get created in the appropriate JIRA project based on a rule support teams can view queues which contain only their support tickets customer portal supports a hierarchy (so that the initial options are high level, similar to a phone tree) Our IT teams support hundreds of different applications, and we don't expect users to know which applications are supported by which teams. This should be a simple and seamless experience for the user. Our JIRA projects are actually broken down already by teams (100+ projects). So having 100 teams all shoving support tickets into a single bucket will be chaos – we need the ability to auto route the tickets created by a unified customer portal to the appropriate JIRA projects. A hierarchy for the customer portal is needed so that we don't have 1000 things to scroll through when the user visits the unified service desk. (we agree with your presenter at summit, if we make it complicated for users, they will go around this process instead of going through it) With regards to the unified customer portal, we would also like to be able to configure which confluence spaces (kb articles) get hit at different levels. It may make sense to (as atlassian reps mention in this thread) be able to set up a master customer portal, and inside it, teams set up their own service desks, with links to their own confluence spaces – This setup is probably fine as long as we can make it invisible to the customer. They should see only one service desk in the drop down.

            Same here. Any news on if and when this will be implemented? This is stopping all my customers from using Service Desk.

            Sandra Axelsdóttir [Tempo] added a comment - Same here. Any news on if and when this will be implemented? This is stopping all my customers from using Service Desk.

            Saori Nakai added a comment - - edited

            This is a really important (blocker) feature for our organization. Without it, Service Desk won't work without a significant reorganization of our processes. Is this a feature you plan to implement? If so, is there a timeline?

            Saori Nakai added a comment - - edited This is a really important (blocker) feature for our organization. Without it, Service Desk won't work without a significant reorganization of our processes. Is this a feature you plan to implement? If so, is there a timeline?

            Utilizing one service desk portal for the entire company to direct to, and splitting requests/issues based on entry in the portal is definitely a need for us. Several internal problem response teams, and just as many ways/directions to create tickets. Centralizing the portal, and directing to affected projects would be a solid user experience gain.

            Josh Harper added a comment - Utilizing one service desk portal for the entire company to direct to, and splitting requests/issues based on entry in the portal is definitely a need for us. Several internal problem response teams, and just as many ways/directions to create tickets. Centralizing the portal, and directing to affected projects would be a solid user experience gain.

            Agreed. We have multiple support teams for different types of requests and would like to be able to filter issues into particular support team projects. Implementing this feature would allow us to use one Service Desk for our entire IT organization.

            Casey Feskens added a comment - Agreed. We have multiple support teams for different types of requests and would like to be able to filter issues into particular support team projects. Implementing this feature would allow us to use one Service Desk for our entire IT organization.

            This is a huge blocker for us. The purpose of Service Desk is to provide a simplified entry process for users. Having to manage multiple Service Desks and expecting clients to switch back and forth to submit as well as to track their requests is not feasible. The user experience must be that a single portal allows submission to multiple projects (routed according to configuration within the specific service desk request item) as well as monitoring of their requests. Not sure I could see it working any other way. I'd add that it would be ideal if a request's routing to a particular project could be driven by the selections made in the request.

            dbroyles_turner added a comment - This is a huge blocker for us. The purpose of Service Desk is to provide a simplified entry process for users. Having to manage multiple Service Desks and expecting clients to switch back and forth to submit as well as to track their requests is not feasible. The user experience must be that a single portal allows submission to multiple projects (routed according to configuration within the specific service desk request item) as well as monitoring of their requests. Not sure I could see it working any other way. I'd add that it would be ideal if a request's routing to a particular project could be driven by the selections made in the request.

            Could you please advise when this feature will be available?

            We are at a critical point of implemented the Service Desk for multiple R&D projects and cannot proceed without it?

            IT Department added a comment - Could you please advise when this feature will be available? We are at a critical point of implemented the Service Desk for multiple R&D projects and cannot proceed without it?

            Nascom added a comment -

            This feature together with the JSD-160 would be crucial for us to start using it for all our customers.
            Evaluation of the Jira Servicedesk otherwise, is going fine (great first version of the product) but this lacking functionality is considered blocking.

            Nascom added a comment - This feature together with the JSD-160 would be crucial for us to start using it for all our customers. Evaluation of the Jira Servicedesk otherwise, is going fine (great first version of the product) but this lacking functionality is considered blocking.

            As a centralized Support Team we need to manage our support queue over a range of projects. Having several service desks is not an option (in fact a downgrade), as well as having a single support project for all our customers.

            Our idea was to have queues per project/product and an overall queue, but you can't trick the project restriction with JQL.

            Any ideas for the time until this issue is fixed?

            StephanieC added a comment - As a centralized Support Team we need to manage our support queue over a range of projects. Having several service desks is not an option (in fact a downgrade), as well as having a single support project for all our customers. Our idea was to have queues per project/product and an overall queue, but you can't trick the project restriction with JQL. Any ideas for the time until this issue is fixed?

            Sean Cull added a comment -

            Sean Cull added a comment - This is now the 2nd highest voted request https://jira.atlassian.com/issues/?jql=project%20%3D%20JSD%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

              Unassigned Unassigned
              dcurrie@atlassian.com Dave C
              Votes:
              159 Vote for this issue
              Watchers:
              123 Start watching this issue

                Created:
                Updated:
                Resolved: