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.

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

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

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

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?

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.

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.

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

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

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?

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. =/

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! =)

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?

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?

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

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

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.

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

Any update on this feature in JSD

Me too!

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

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

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!

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.

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.

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?

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

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

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

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.

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

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.

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.