OMG. This just goes on and on. Why won't Atlassian just fixes this already? And not without needing to buy an additional plugin.

@Jan Kuntscher
Totally get that, but I'm not willing to throw more money/resources onto a feature which should be available in the first place.
We use a different tool since a while and reevaluating SD again once the other tools subscription is up for renewal. Fortunately we noticed this gap in an early test phase and we never had to deal with real customers on it Only downside is that our solution now is not integrated in the Atlassian eco-system we have.
~Mark

All,

For a very long time, I was upset with Atlassian about this "gap" in functionality. I followed this thread and occasionally posted about my frustration. A week or two ago, I decided to take matters into my own hands and started investigating what I could accomplish by leveraging the main Jira API and relatively new servicedeskapi. The APIs are very robust and I was able to whip up a quick PHP script to accomplish this very thing. I am no master at programming - in fact, it had been a couple of years since I had written anything production-worthy - we have a team for that now. That said, I was able to whip something up in about 20-24 hours.

Furthermore, I learned a lot about Jira and Service Desk in the process and, in addition to solving my participants problem, I was able to build functionality into my scripts that actually solved or otherwise streamlined other business processes. Let me reiterate, I was no fan of Atlassian over this issue but I finally decided, instead of complaining, I should try to find a solution. The Jira API and servicedeskapi are actually quite robust and if you all take a moment, I think you too can find your own solution to this problem and make your Jira instance work for your business needs even better than it does today.

For the record, we are using Jira On Demand and the solution works perfectly. I know not all of you will be able to just whip a program but I do think there are options. If this is the route you decide to pursue, feel free to reach out to me if you have questions (brendan-jira@turinggroup.com). My schedule is busy but if I can answer any questions and I have a free moment, I would be happy to.

Finally, I did run into some bumps along the way - after all, our Service Desk instances are customized quite a bit. When this happened, I simply opened a ticket via the Atlassian Support page and we worked together to get to the bottom of it. They were quite responsive and helpful.

Thanks and good luck,

-brendan

"Collective Issue View for Service Desk" plugin only works for Server installations so it's no use those of us that use the Cloud platorm

@Mark Bednarski: The Plugin is not from Atlassian. It's from //SEIBERT/MEDIA, a Platinum Expert Partner. It's your choice, either you are waiting for an unknown time till Atlassian releases a fix or you try & buy the plugin so you can concentrate on more important things and not on "ridicoulous" ones.

WIth the Promo link mentioned above you will get -50% off till 1st August.

@Oliver Capalad: Take a look at the "Collective Issue View for Service Desk" in the Marketplace. This solves JSD-720

Link: https://marketplace.atlassian.com/plugins/net.seibertmedia.jira.plugins.collective-issue-view/server/overview

Any update on this? Due to this limitation, our customers are not happy and are moving away to use JIRA Service Desk.

Via a paid plugin? You must be kidding. This is getting ridiculous. Key feature gap. .

Not even Atlassian knows.......

@Job Vermeulen: //SEIBERT/MEDIA is a german Platinum Expert Partner and one of the five biggest worldwide. We have nothing to do with the comment you mentioned, but we know the pain and we wanted to provide a solution for this very important feature as soon as possible (also for our customers) and no one knows, when Atlassian will release this feature.

Agreed with Job. Not going to pay for a mistake of Atlassian's.
They need to fix it, and this is taking far too long for amount of people showing interest in this.

@Jan Kuntscher is your company referred in the Atlassian comment 'This is one of our highest priorities and we have the best team working on the feature.'?
Personally I would expect a solution for this problem to be native instead of a paid plugin.

Are you planning a cloud version as well?

That is sad.
I was hoping that Atlassian can install it on support.atlassian.com before they will be able to release their own solution ....

@Hisham: This is a server only solution.

@Jan, please advise if you have a could version

COLLECTIVE ISSUE VIEW for SERVICE DESK

Available now! Limited-time launch pricing: 50% off till 1st August 2016

Promo link: https://promo.atlassian.com/CYFP3W

Hi all,

we are happy to present to you our plugin which solves JSD-270: https://marketplace.atlassian.com/plugins/net.seibertmedia.jira.plugins.collective-issue-view/server/overview

It's available in the marketplace. We hope you like it. We made it to participate on Codegeist 2016 and of course because we know the pain of this lacking feature.

If you encounter problems or want to suggest new features please use the plugin's support link provided in the marketplace.

Best regards.

Jan Kuntscher

Product Owner at //SEIBERT/MEDIA

Our company's main issue preventing us from taking this Service Desk software on, is potentially hinged upon this feature. This is why we need it:

• Assign multiple users to a company or organisation
• Have a view/run reports on incidents per organisation
• Assign a 'supported/unsupported' status to an organisation
• Assign SLA timers to an organisation

There are other things lacking, but can be fulfilled with various plugins available, but this feature(s) is the one that's stopped us in our testing.

Hope for something to test soon.

Hi all,

Happy to find this issue.
Some of our customers need to access to the request created by the members of the group "service desk customers" in the same project. Need access for consulting, comment, and also reopened !
Hope this option will be operationnal soon.

Thanks for your help

Hi Gareth, We have been doing the same, but it only solves the problem partly. It allows them to see all issues in their organisation, but it also means they get spammed with every issue update (as they are participants) rather than just seeing all the issues and only being involved in the issues they want updates for.

Side note: JSD seems like an IT helpdesk only tool rather than a tool to support any JIRA project where many organisations are trying to use it to support ongoing project work either with different customers and/or same customers but different departments for that customer.

We are currently finding it VERY hard to find a way to collaborate with our customers on development projects using JSD. Does anyone else develop new projects for new/existing customers where you would like the customers limited input/visibility on issues but let them see where general progress is at say with the current sprint or epic? Giving the customer some sense of visibility/transparency as to where the development project is at rather than just spreadsheets or emails etc? Surely this is possible in 2016? (Hopefully with Atlassian?) (Tried showing them through confluence - as a confluence user though - but this failed also as only jira users can see linked JIRA issues/reports in confluence...)

Thanks for any suggestions!

To share issues between customers (users), I've started using the Request Participents feature by using the free Automation plugin. I search for all issues under customer X (which is a custom field) and then update the participents to be X,Y, & Z. Its not great, as you need one automation script for each customer but it works.

@Lauren,
The solution I was referring to bypasses the need for a post function to map the user property to a field value. Their is a custom field type called "User Property Field" in it configuration you can map it to a user field. Once you have created a field of this type you then goto the configuration menu and in the default value you give it the mapping to the user property that you want. In my case I created a project called ORG and all users for a given org have a property called ORG and a value of ORG-####. The user property field I then named ORG Ticket and has a default value of reporter:ORG.

@Wayne and Everyone else
When the ticket is created I have an automation set up to fire a series of transition steps. The first post function of the first transition is: "The Field Epic Link will take the value from ORG Ticket". This allows me to then map any fields that I wish to the customer ticket that is created using additional post functions. Each transition is used as a try fail statement that perform the logic I need to automatically route/assign tickets, add request participants(additional users of the same org) and assign unique SLA requirements.

The ORG project itself was an added bonus since I now had a location that I could map all of my customer details where it was easily source within JIRA and via API, but in the end this solution is definitely "hacky".

This workaround is not for the faint of heart. It took >6 months of exploration and testing to get correct. For me it was worth the effort since centralizing all of work within the Atlassian ecosystem means great efficiency for the team.

@Lauren Shanta - Thanks for the info. Which field are you updating using JMWE to allow the issue to be shared between customers? I use user properties to set the customer already and the issue security scheme in Jira, but I cant see how to open it up in ServiceDesk?

This function is key for us to start evaluate Jira service desk replacing our current service desk.

@JP Rowan - That's exactly what I'm doing - I assign a custom user property to each customer tagging them with a "client" identifier. I pull that into a custom field on every ticket they create which then get used a million different ways, from alerts to resource assignment to client email notifications (hacked through subscriptions and email forwarding) to paging for off-hours emergency production issues. Problem being, I'm on Cloud and they are killing the "Map User Property to field" post function come July 31st, so my beautifully constructed house of cards is about to come crashing down. Manual intervention will be needed for every client ticket leading to all kinds of delays and I have no clue how we'll need to handle off hours emergency pages, if we don't know which client is having the issue. Paging EVERY tech will most certainly lead to my untimely and painful demise. "Panic" does not begin to express my current emotional state. I'm hoping against hope that this new "customer group" construct will allow me to salvage some of this, whenever it shows up, but I'm looking a months of workflow tuning down the tubes and I don't even want to think about the internal retraining issues. <slinks off to sob in the bathroom>

@JP Rowan/Lauren
We also are using a standalone server instance, Im not sure how to work around this using a custom field to allow user to share issues. If there is an article describing a workaround technique to accomplish this, could someone please post a link ? I would like to give it a try.

@JP Rowan/Lauren,
We have a standalone instance, but id be interested to know how you share issues between users using the user properties?

Lauren,
It looks like you may have implemented a similar workaround to what I have. Have you looked into using the User Property Field (< 255 characters) to map the field to the requestor's User Property? The field type is read only and can then be mapped to another field using a post function.

PSA: For those of you using User Properties and JMWE as a "group" work around, be advised that Atlassian is planning on killing the 'Set Field to User Property Value' Post Function when they pull JMWE from Cloud.

https://confluence.atlassian.com/jirakb/jira-miscellaneous-workflow-extensions-jmwe-removal-from-jira-cloud-815262011.html

Their suggested work around is to migrate your entire instance to a stand alone JIRA Server instance.
I'm just hoping this feature gets released in the next month, otherwise my entire Service Desk workflow system will spectacularly implode like a skyscraper in an Avengers movie <shudder>

Please include me in the beta testing.

Daryl White

Also left my details as this feature will be one of the top requirements for us. We're evaluating ServiceDesk (I'm the Atlassian evangelist in our company) right now amongst other products and unfortunately identified this missing feature to be a blocker. So ist there no estimated date for a release? This would help me and definetly others as well to keep ServiceDesk on the table, which is what I want. But right now (looking at other important feature requests for JIRA/Confluence and the long way they're taking) I'm in a bad position to argue for ServiceDesk.

Best,
Max Förster

Thanks for all your interest, please leave your details down on the form provided: https://jsd-beta.typeform.com/to/TUqws8

I'd like to participate in beta testing too.

me too

Hi,

I'll be happy to participate in beta testing.

Regards

Daniel

Hi all,

This is one of our highest priorities and we have the best team working on the feature.

This feature fundamentally changes the way our product work and we want to ensure we get it right. We have been actively reaching out to this community for usability testing on our latest development and design work on this feature. If you are keen to see where we are up to with the this feature, you can leave your details here to join one of our upcoming usability test and provide us feedback on the feature itself.

Thank you all again for your patience.

— JIRA Service Desk Team

Hi everyone,

A while back we posted a link to a survey about this issue, which received a lot of response. We have used the data from the responses to come up with a fitting solution, but we weren't able to build it straight away because we weren't able to integrate with some parts of Service Desk yet.

Atlassian has recently opened up these integration points and we have started working on building a solution into one of our JIRA Cloud add-ons. At the moment, we don't have an estimate on when we will be able to release it to the public.

We are now looking for people who are interested in beta-testing the add-on once we have implemented our solution. We still have a lot to do, so it will take a while before we can start beta testing. But if you are patient and using JIRA Cloud, shoot us an email at: addons@avisi.nl.

Cheers,
Maarten

We are actively seeking alternatives due to the lack of commitment on this issue. I am very disappointed as I am otherwise a big fan of the Atlassian product suite

I have been pushing back a request from senior mgmt within my organisation to implement alternative solutions because of this very specific request. However, given the length of time that has passed since raised, we have no option but to look at alternatives.

My only assumption is that there actually is no development in place to address this request, within Atlassian and that perhaps the hope has been that a 3rd party add-on would provide the necessary functionality?

Regardless, the handling of this request has been nothing short of farcical. I have not seen an activity on the account Shihab Hamid [Atlassian] since May

I don't want to add more oil in the fire, but I couldn't agree more with @Neil.

I think this is not true...

Thank you for all the responses so far. We truly understand the importance of this feature and take your feedback seriously.

@ Neil. I added much the same comment several months ago to no avail.

I've historically had to raise a support ticket on our own account to ask them, to ask the product team, to respond to this ticket. Someone else can feel free to do same, and we might get a response - no one from Atlassian clearly bothers to read any of these comments, despite it being top priority.

An absolute joke of an organisation, with no regard for customers whatsoever.

Dear Atlassian,

On 4th Dec this issue was reported as on the roadmap. Where on the roadmap was not reported.
10th Feb it is reported as the team highest priority.

in May you don't even have an meaningful e.t.a. to provide.

No offence, but this seriously calls into question the competence of your development and ironically, your planning, as you have had half a year to even get a basic plan of when you can schedule this in, yet there is no news.
I don't think anyone is looking for a delivery date, a basic plan as to when they might expect it would be good.

if this is the highest priority, the lower priority issues presumably will not be done at all.

Agreed with Timothy. This is going to limit us massively as we introduce the Service Desk to more and more of our clients. After speaking to senior management it's possible that this could result in us having to look into an alternative solution if this isn't added soon. Some communication would go a long way.

Atlassian Support Staff,

Can we please get a status update on this task. It has been months since we have had any notification from Atlassian regarding this issue. With over 1000 votes, 700+ watchers and 300+ comments, surely we deserve consistent updates on progress. This is a significant business decision pending for majority of those who are watching and many of us have executive management pressuring for a response and updates. With nothing to provide i am consistently looking like a chump.

Our Development team uses JIRA Software. Our Support team currently use a competing product and have considered moving to JIRA Service Desk, but it is not an option until this feature is available.

We have implemented JIRA and used 1 Service Desk for all of our clients and differentiated them between a custom field called 'Client' (due to the multiple Service Desk approach being impractical for a company with 1 small Service Desk)

There is a demand from our clients to be able to see all tickets logged by their organisations so they can be reviewed in meetings so having this is essential.

I have to agree with dwhite3, this is one of the features that I expect to be within SD by default...

This really is a major issue and prevents Jira Service Desk from being a Business to Business solution. If this can't be resolved soon we will need to find another product.

@Donna Menhennett:
I also use 1 Service Desk project for all customers. So I was concerned about your comment as well.

I logged in as a customer to check if the user could see tickets created by somebody else when filtering on "Created by anyone". But that wasn't the case. So I'm not sure what this filter currently does.

The implementation at present appears to be that for any ticket created through the portal, for a given project where a user has been designated a role within - if the user chooses "Created by anyone", they will see their tickets and any ticket they are a participant on.

The ticket must be created through the portal, AFAIK, i.e. if added as a participant to a ticket which was created through the backend JIRA interface, I don't believe they will see these tickets under the "Created by anyone" filter.

@Donna Menhennett - the filter appears to be contained within the given Service Desk project, not across the organisation.

It's still a long, long way from the final solution, as this requires an agent to add multiple customers as participants to every single ticket. What would happen if we had >50 individual customers within a given project! It really makes no sense that all customers cannot see each customer ticket created for the project, once the ticket is created by a customer role user

Hi all,
it seems like some progress on online version!!
if we add a user as participant on a case and we select created by anyone we are getting some results ( we are checking on the filter results now)!!

Hope this helps!!

Regards
Anish

@Wayne Bene, we raised a similar concern to yours with support, in that the function for customers to see more than just their own issues appears to be there, but not working.

Again we were directed to this support page - so yes i think your issue is the same as ours and others within this ticket

@Atlassian Could you give us in the mean time a multiselect group field to set the participants as agents? That would really help with the biggest pain...

We are having the same issue. It seems as though the drop down boxes for "Created by anyone" or "Created by me" have no effect in changing the search results. Is it a query issue or is it a permission issue at the project level ? Is my problem the same issue ?

We are using cloud version of Jira and right now when we go to helpdesk we could see options of "Created by any one " and " where I am a participant" but when we are selecting this option we are not able to get any of the issues logged by customer contacts where they are bing added as participant.. we are persuing a huge deal with Jira as our customer service portal.. this is a vital feature which we need for qualifing Jira to be used as customer portal option.. please help us in clarifying the same.

While some suggest Teams for JIRA as a workaround - it works and does not work at the same time. When tickets are done via email requests or an agent creates the request - it doesn't assign the appropriate Service Desk Team. Since 99% of our requests come from email, we always manually have to add the Team to the request.

I wonder if Atlassian could work out some deal with Prepend (makers of Teams for JSD) to maybe work with them to offer a discount on their plugin until the feature is implemented directly in JSD? Just a thought that might be a good option until then...

"The inability to have this functionality in place is a major, major weakness of JIRA Service Desk compared to competitor products. I believe the mentioning of Groups and Crowd above is mudding the water somewhat and IMO, the amount feedback on this specific issue is an indication of how much myself and others wish to continue to utilise the many great aspects of JIRA and Service Desk, but are being called-out on this point by our customers and in that scenario, we are being left with very little option but to seek alternative solutions, which I would genuinely rather not have to do"

This is our exact situation. We have 6 Jira instances and use Service Desk to support 2 customers so far and are looking to expand quickly. However, we have been given an ultimatum that either this functionality is available for the next delivery cycle (fortunately at the end of the year), or we have to switch products. Obviously, and unfortunately, that means we will move everything as supporting two or more service desk products is an unnecessary overhead.

Why can't we even get a guideline estimate or any insight on this is?

@Vincent Wong While I and others appreciate that changes would be necessary to the underlying user management architecture to enable the original request outlined above - however, re. user management and permissions, I am struggling to understand how restricting visibility to Customer X's tickets (where reporter is a Customer within Customers X's organisation), to all Customer users within Customer X's organisation, is a risk and cannot be implemented with greater haste?

The inability to have this functionality in place is a major, major weakness of JIRA Service Desk compared to competitor products. I believe the mentioning of Groups and Crowd above is mudding the water somewhat and IMO, the amount feedback on this specific issue is an indication of how much myself and others wish to continue to utilise the many great aspects of JIRA and Service Desk, but are being called-out on this point by our customers and in that scenario, we are being left with very little option but to seek alternative solutions, which I would genuinely rather not have to do

Vincent Wong: "We understand many of you will need to make business decisions around when this feature is available, however we do not have a meaningful ETA we can share. As mentioned in my previous comment this is already in active development but there are quite a few number of moving parts to implementing this feature. "

Appreciate it might be more complicated, but how is it possible at this point after this huge period of time that Atlassian doesn't have a scope, plan, specification and estimates to complete the work? Absolutely ridiculous to not even be able to narrow this down to a quarter e.g. Q3 2016. If this can't be done, we all have to assume Atlassian is not able to deliver on any timescale which is acceptable to our various businesses.

We certainly have no choice but to start planning our migration of dozens of Service Desks and hundreds of users to another platform (likely Zendesk) within 3-4 months, and take our business elsewhere, as the product is not currently fit for purpose.

Simon

Just chiming in for my org...maybe we're in the minority here, but we just use Service Desk internally. We don't need any additional permission models than the one that ships with JIRA. What we liked in Service Desk 2.X was that it respected JIRA's security schemes, and it's part of the reason why we're stuck in JIRA 6 because upgrading to 7 means we'd have to update Service Desk and struggle with JSD-270. I really hope source code becomes available (JSD-397) so we can workaround some of these issues.

Speaking of Crowd, I filed this bug with Service Desk not too long ago: JSD-3586.

Also, escalating admin actions to Service Desk users/agents didn't really work well for us in the past (users creating their own custom fields via SLAs, forking permission schemes, and JSD-3586). Please consider the impact. Thanks.

@Vincent: VERY Important - If using JIRA groups these groups cannot be renamed and this is very problematic. If we name a group by an organization and that organization changes it's name we are stuck!

@Dave Thomas and @Vincent Wong; also pay attention to this issue: https://jira.atlassian.com/browse/CWD-4634 (No difference between users that has "Admin" rights and Non-Administrators users). This is already a (major for us but apparently minor for Atlassian) bug. When you implement Service Desk group functionality and want SD agents managing groups you may not want them to become System Administrators! Especially when you have only read and not write implemented from Crowd or any other LDAP this will be impossible for any customer to use!

@Vincent - Please bear in mind that some of us are using crowd for user management. Crowd seems to be a forgotten stepchild these days, but please don't break it with these changes. Thanks for taking the time to make sure this is done correctly and tested thoroughly.

Hi,
as far as I know it is possible to add watchers only at issue creation, not in a later phase.
Massimo

Right now we are in the process of bringing in groups into JIRA Service Desk (Ability to add groups to tickets, JQL search for groups etc) and also making enhancements to the group infrastructure (Allowing agents to be managing groups etc).

I like this, very nice

Hey all,

We understand many of you will need to make business decisions around when this feature is available, however we do not have a meaningful ETA we can share. As mentioned in my previous comment this is already in active development but there are quite a few number of moving parts to implementing this feature.

We will do our best to keep everyone updated with the latest development regarding this feature and to share our designs/progress once they become available. Right now we are in the process of bringing in groups into JIRA Service Desk (Ability to add groups to tickets, JQL search for groups etc) and also making enhancements to the group infrastructure (Allowing agents to be managing groups etc).

Again I want to stress this feature requires big changes to our underlying user management and permission infrastructure. Both of these aspects are fundamental to how you manage your users and the access control of the system, and we need to take the time to make sure we are doing it in the best possible way possible. Thank you again for all your continuous feedback and I will do my best to make progress updates as we go along.

-JIRA Service Desk team

+1

+1

+1

Hard to explain to my clients as well. This is the main reason I have not yet left Freshdesk for all my clients. But straddling two platforms is obviously painful.

+1 As a cloud user I feel extremely let down by the lack of firstly the functionality to begin with but secondly that while a Server workaround exists, ONCE AGAIN no such option exists for On Demand!

The absence of this functionality is actually embarrassing when explained to our customers, who cannot understand its absence on what is otherwise a comprehensive platform.

I cannot urge you to enable for On Demand with enough urgency

Seconded. Cloud is great for my team, but it's disheartening to tell them "sorry, we can't fix this yet because we don't have the hosted solution." I hope every Cloud user is following and voting on this issue!

There are always work around addons for Jira Service Desk Server version. It is us Cloud users that are always left waiting for these types of solutions.

Teams for JIRA Service Desk is a "Server" only solution so not a workaround for Jira Cloud users but thanks for the comment.
https://marketplace.atlassian.com/plugins/eu.prepend.jira.servicedesk-teams/server/pricing

As a workaround we use the add-on "Teams for Service Desk"

Hi Ben,
Would you care to share how exactly you managed this?
We would like to test this feature with our internal teams
-Paul

Adding support for this functionality - We are ready to use JSD if this is implemented. Could you not just allow a feature to have groups view all issues from others within the group on the customer Portal.

Just adding my vote to this feature.This is something that is very important to my organization. We love Jira but will have a hard time implementing service desk without this feature completed.

Our company is looking to migrate to Jira, Jira Service Desk which cannot go ahead without the ability to group customers by the organisation and for customers to see all tickets raised under particular organisation.
Really looking forward to find out when will this be implemented.

Please can we have timelines for delivery of this feature.

Our business is standing by ready to migrate to JSD. The only blocker is this missing feature - frankly, it's surprising that the product was even launched without it!

This is something that we expect to get for long time. Limiting customer access based on grouping customers from same organization is essentially important so that we can avoid managing multiple SD projects.

We are trying to collaborate with another company who also uses Jira service desk and we need this ability.

@Dave Thomas Thanks for the info Dave. We are going to save off our data and wait for the server version to catch up to that save. We likely won't get an exact match, but hopefully enough of a match that the data is functional in our server instance. I agree with you, current Cloud version will always be ahead of current server version.

When did you do your migration Dave? We did a pilot of it a few months ago and it went fine. When we went to do the real migration last week, the versions have become too disparate and we got the errors I mentioned. We're hoping they drift back to each other eventually.

I don't want to get off topic for the JIRA this pertains to because it's going out to people who aren't interested in this side topic. I moved it to here: https://answers.atlassian.com/questions/38383036/has-anyone-reinstalled-their-cloud-version-of-jsd-into-a-server-version-to-use-teams-for-service-desk-and-how-did-it-go

@Valerie - I've done a migration from Cloud to Server before and there were definitely some issues. In our case, all of the data came over fine but the project settings and permissions were all incorrect. We were able to correct those problems and move forward. If you contact Atlassian support, they should be able to help you through it. I'm not sure if it's possible to wait until the Cloud and Server versions are at the same level – I think the Cloud version is constantly updated and will always be ahead of the Server version.

@Valerie Boudreau, we have been using it since three weeks after it came out on the marketplace. The few issues that I have had with it, their development team has been very quick to resolve and have a new version out in a few days and have been very responsive to questions. As to functionality, it does exactly what it says it does as to allowing groups to access a ticket tied to that group id. I have over 25 groups of users using it and it gets little to no complaints while keeping the groups isolated.

@Valerie Boudreau, we use it and it works pretty well on our server versions of JSD. We also had a couple issue with the plugin and turned out it was mostly javascript problems with another plugin (in the customer portal only). We are working with them to try and isolate the problem, but I would use the safe mode feature under add ons if you want to investigate it a little further, trying to turn off certain plugins to see if you have any problems. It was weird, but started to make more sense once I turned on the JS debugger and looked up some of the problems I was getting. Good luck!

Is anyone else using Teams for Service Desk and do you recommend it? I got approval for us to go from JSD On Demand to a server instance so we could use it. We set up the server instance and attempted to do a reinstall of our current service desks. The install failed because the Cloud version On Demand is on is higher than the server version that's available. Our project data is there, but none of it is connected to any of the navigation. Projects, Boards, etc., dropdowns blank. We can do a search and find issues, but they don't even populate the dropdowns as "last viewed" when you leave the page. We are considering manually reentering all of our open tickets, and saving off a back-up of our historical issues and waiting for the server version to get up the current Cloud version and attempting to install them into the server version again. Before we do this we'd like to be d**n sure Teams for Service Desk is worth the work.

@Paul Bijlsma thank you for mentioning the plugin Teams for Service Desk.
If it does what it says on the tin, then it would be exactly what we (and I think most other people in this topic) need.
I see that it´s Paid via Atlassian and we are Open Source users, so it´s basically free for us.
I cross my fingers for cloud customers, but I am unsubscribing from this topic because I have a solution.

We are using service desk without this feature and our customers are not happy, not to mention we are getting many duplicates and spend a lot of time answering inquiries on other tickets within the client's company. We've been forced to have bi-weekly meetings to go over every issue by one company so that they can all be on the same page. One company has agreed to use a mailing list and all their people use the same account so we never know who we are dealing with.

+1 for javajoe's comment. No dice for OnDemand users that are still paying Atlassian for a service/product not provided. Looking forward to implementing zendesk in a few months by the looks of it...

Teams for Service Desk is not available to cloud customers. Still no option, paid or otherwise for us

Thank you so much for the info Paul.
We'd like to move over to JSD, but not until at least this is included.

Good to know there's an option that may be helpful to others.

Hi @Olof, yes it is:
https://marketplace.atlassian.com/plugins/eu.prepend.jira.servicedesk-teams/server/overview
It was the price we had to pay to allow us to go live with Jira Service Desk. Not having this functionality was an absolute show stopper for us.
I could not wait for Atlassian to implement this (in my mind) critical function for an enterprise service desk tool.
PS: Consider that this plugin will also require one additional agent user license... unless you want it to perform its operations with an account shared with an actual agent.

@Paul - that's a paid plugin?

I am succesfully using plugin Teams for Service Desk in production.

My customers can see all other requests raised from other people as long as those belong to the same Teams (configurable Customer group). My group configuration comes from Active Directory, so once the structure was set up, there is no configuration afterwards.

Customer can choose to join requests from others in their team to become request participant and start adding comments and attachement and receive updates.

I would like this feature as well. From my perspective, the design would be that there is a way to "group" external individuals together (members of the same company, for example). Once such groups exist, it would also be nice if there was a way to chose if all members of the same group can automatically see each other's tickets or not (but on a group by group basis).

Without this functionality, individual users from a given company on our Customer Portal need to manually "+Add people" for each ticket they open (when they remember to) for this same functionality.

That's a nasty feature. I added attachments to a post I was writing, decided not to write the post and Cancelled it, and the attachments posted anyway. Cancel means Cancel.

I don't want to pile on here but this is coming to head for many of us. We have stuck around because we love Jira. I know I do. I particularly love the promise of SD. That said, I am getting tired of making excuses for why the Service Desk we provide to our customers can't do something as simple as this. I don't know about the rest of you, but I NEED a firm date so I can quit making excuses. I have looked at several other options that have this. I do not want to make a change but it is getting to the point where I might not have an option.

ATLASSIAN - PLEASE MAKE A COMMITMENT - WE NEED IT!

I'm glad they are doing this, but I am not convinced that the way they seem to be implementing it is going to work for us.

For example:

• Service Desk users already require administrative permissions for the entire application just to create customers (because they have been implemented as users). This is rather ridiculous! None of the other systems we have looked at require this as it's just a basic thing that support staff need to be able to do. Support staff should not have administrative permissions!
• Altassian seem to be saying that they will implement organisational accounts with groups - but again, Service Desk users will require full administrative permissions to manage groups
• We have many contacts that call up for support that do not have email addresses. We can't add them as customers - so how do we track their support tickets?

It will be good to have this feature, but unless they solve the issues above, I'm not sure how this can be used for anything but a very basic internal ticket system.

This, plus the ability to set custom fields based on organization when customers create requests.