HI,

we are analysing service desk for use as a customer support portal for our organisation. We have been to now using the cloud based JIRA for our customers. Our customers are required to include detailed information when raising issues and are not naive users of JIRA. For the purposes of consistency we have a number of custom fields the customer must fill out in order to provide sufficient information. They like to have visibilty and as much control and input into the issues as possible (or we allow), so from our perspective the service desk portal is far too limiting.

We have complex workflows to fulfill our needs and have avoided custom or commercial plugins. Our displays have a number of custom fields, some of which the customer may edit via a workflow transition for users in specific project roles. Customers have the ability
to create issues, transition issues, add comments to assist with progression through the workflow and for request and provision of feedback which to us represents a stop the clock situation. Once an issue is created it is assigned to an engineer by the project lead, to be worked on through until resolution. The customer signs off on the resolution by closing the issue. We have the ability to hide comments by setting the permissions level i.e. the customer has permissions to see and do a subset of what the internal staff do based on the use of project roles and permissions schemes.

We require to be able to continue to use these workflows and simply add the SLA functionality into the situation.

Some more specific requirements from our perspective:

1) the SLA functionality should be stand alone (full service desk functionality not required) and be able to be integrated into JIRA cloud services
2) the SLA functionality should support calculation of response times and resolution times, and within this configure holidays, weekends and business hours and some states where 'stop the clock' is relevant e.g. waiting for feedback. The SLA functionality within service desk seems to fulfill these very well and we are happy with it, however currently it only supports states in the configuration. Allowing the use of custom fields here would also be beneficial to us. e.g. instead of having response time set by a transition from OPEN to IN PROGRESS, optionally being able to include the first comment or assignment to an engineer time may also be useful.

3) the SLA metrics shown on the page should be able to be able to be optionally hidden from the customer

4) the SLA functionality should not impact workflows and allow transitions, editing and creation of issues if so desired

I am hoping some of this might be possible and perhaps more easily done than modifying service desk itself. Would you kindly provide some feedback on the possibility of this occurring.

I am already looking at alternatives. I am tired of waiting and getting minimal updates.

ronanl: We shouldn't have to pay thousands of dollars more for a plugin to give us a few buttons which should be part of the base Service Desk.

Atlassian doesn't care anymore. Not sure why we're still paying thousands of dollars a year for them to implement feature we need if they are just going to ignore our needs.

Sorry to be going over old ground here, but just so I'm clear

• for cloud customers, the Service Pack for SD offers a way to address this gap
• for download customers, we are waiting on Atlassian to include the functionality in a new release, whenever that may be

Is that correct ?

I for my part like JIRA because of it´s flexibility and configurability to any need. This recent tendency to "minimise the complexity" is something which worries me greatly! I think Atlassian is going the wrong way here, and if this continues JIRA 8 with ServiceDesk 4 will probably be a product I don´t want to work with anymore...

It's a pity to understand that feature which looks fine in your own service desk is only internal and you don't want to implement it for all your clients. This buttons are really important feature.
Please implement it for us as fast as you can.

This is an major issue for us in using the service desk as our customers need to be able to transition issues as we are able to do on your service desk. At this point we would be happy with the basic functions that you have implemented in your customer portal.

For Cloud

Service Pack for SD helps you

Hi. Do you have any plan for this property for customer portal. This is so so so important

during our evaluation we reached now a situation where
we have to decide "continue or break".

The backend side of JSD looks pretty cool and Jira underneath
is giving a great power and possibilies.
But the frontend side to the customer lacks a lot of features.

This feature is an absolute must-have for us.

Is there a rough timeframe for this feature?

Hi Edwin,
Thank you for The update.

Even though your own service desk is highly customized, then I still do not get why you leave out functionalities in JSD which your support team is clearly using.
If you haven't already done it, then I suggest you talk with your own supporters to understand what features they need, and already uses, for their service desk.
Next step could be to make a confluence page with a list of those features, where we (customers) can add our votes to the features we would like in JSD.
By doing this I believe you get the most important features covered for making JSD the perfect service desk.

For this issue I believe you have received plenty of feedback in regards to what transitions we would like a customer to do, so now I personally hope this feature will be in the next update of JSD

+1 for Andrew's comment

In addition to the use cases for escalating, closing, reopening, it looks like an ability to pause / freeze a request is also another one that I’ve heard from you. Thank you for sharing your use cases.
In considering how we can support this feature request, we’ll be directing our focus to solving these use cases first. As some suggested, our likely approach will likely focus on transitions that do not involve workflow transition screens first.

Again, why not give us the freedom to choose what transitions we want available to our customers? Why limit it to a set of pre-defined transitions? Transitions which require a screen may add an extra click for the customer, but let us choose whether we want that or not.

Thanks for the update, Edwin!

Hi all,

Thanks for all your feedback and responses since our last update on this ticket. In addition to the use cases for escalating, closing, reopening, it looks like an ability to pause / freeze a request is also another one that I’ve heard from you. Thank you for sharing your use cases.

In considering how we can support this feature request, we’ll be directing our focus to solving these use cases first. As some suggested, our likely approach will likely focus on transitions that do not involve workflow transition screens first.

At this stage, I can assure you that our team is well aware of this issue and it is high on our agenda.

There have also been some a few questions about our usage on support.atlassian.com and why it is different to JIRA Service Desk. To explain, JIRA Service Desk is a product designed to address as many of our customers’ needs as possible in the best way possible - but that is not the objective of support.atlassian.com. support.atlassian.com is (and actually always has been) a highly customised instance of our products - most of the customisations predate even JIRA Service Desk itself. There are many peculiarities of support.atlassian.com that will make it impractical for us to ship as is - e.g. it expects a “hardcoded” set of transitions, fields, etc. For the JIRA Service Desk we want to ensure we are shipping the right product.

Thanks!
Edwin Wong
Service Desk Product Manager

Expecting this functionality soon, As customer should be able to resolve the issue, if further action not needed from support...

OK now someone from Atlassian need to come up with answers.
JSD 2.3 has just been released and these are the issues resolved.
JSD-269 got 198 votes, good to see that it has been resolved. Now we just need to see this issue be part of next release.
@atlassian, please give us an update here!

Atlassian it would be great as well to respond how many customers MUST suffer that you work on some improvements ?
This case has 250 votes. So 250 customers suffer and you provide this functionality in your own portal.
There you have a "reopen this issue" link.

I fully agree with the feedback from the other customers.
I guess atlassian changed over time from a company providing good tools for customers to a company wanting to get most
money from customers with minimum effort.
I 100% agree that several base requirements are not fulfilled with the product and you have to wait years to get if at all
some improvement.
This is not how it should be. If atlassian claims to follow "eat the own dog food" philosophy than really do it.
The customer portal looking like service desk has plenty of functionality which aren't available for the customer.
It's clear why as the base product is missed plenty of base features and would not be sufficient.

Unluckily we customers recognize all this gaps too late and so you have to suffer or switch to another product.
This costs as well money.

So it would be great if the product manager sometimes ready this posts here and atlassian changes the way to focus on providing
features which MUST be in place.
The same is valid as well for confluence. We have plenty of plugins we need to somehow handle this product.
Bulk Labeling for example, Bulk Changes of pages

Yep that has been raised a couple of times.
I have even complained to Atlassian support about the missing functionality is found in a plugin, which will cost me 1000$ more. Support directed me to this issue, so here I am together with the rest of you

Actually it might be the functionality that comes with ServicePack for ServiceDesk (https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.jsd-extender) as buttons are the same - a paid plugin unfortunately.

They are using JSD, with their own customizations, which aren't included in JSD for their customers.

@Charis Psarropoulos
from the bottom of my last support ticket:

What I don't understand is that a crucial tool like this is not being tested by a select group of customer of Atlassian (with a discount on the price). So this group of customers can give feedback to Atlassian in what works and not. Even address if something is missing. Atlassian can decide what they want to fix/adjust or not. And when all works fine then and only then Atlassian can put this on the market.
Right now I (as a customer) get the feeling that this product is not finished and is missing crucial elements and functionalities.

I really hope Atlassian will improve their test possibilities and there way of communicating with her customers. I would suggest to be more open about issues that are created and when an issue will be fixed. Don't use a voting system if this is not a leading part of your process.

Atlassian please be more open and transparent and customers will understand you better and they will become more patient (manage the expectations and try to unburden your customers).
I really love the applications that you made Atlassian but please don't ignore your customers and make sure you do it right or not at all.

I have been on this thread for a long time now. Atlassian has been ignoring this. We got one comment from them I believe in December of last year but no indication of where they plan to go. I have a deadline of the end of this month and I will then start to look at alternatives to Jira. I cannot run my business as is with SD and the cost of going to the next level of Jira with the added costs of the add-ins for the next level is out of the question. Appears we can be here moaning and groaning but it has not made any difference in the past 8 months. I am very disappointed of the lack of customer service and lack of communication from Atlassian. What a way to run a business. Must be that there is no competition? I do not know in that I have not searched yet.

I'm kinda tired being treated like a milk cow beta tester here..
Atlassian, take a stand and communicate

I completely agree with @Matt Sommer's speculation. In fact Matt beat me to it for posting this revelation. Disabling transition for customers is the only "Band-aid" solution Atlassian has, to work around the licensing issue.

So we are kind of barking up the wrong tree here.

Just mentioning that as Atlassian themselves have claimed, they are NOT using SD for their support, only a highly customized Jira instance. So, these functions are not there for Atlassian's SD, since there is no such thing (comment made 29/Oct/2014).
Having the ability for the customer to proceed within the workflow through the SD interface is essential for us too and it is a serious point of consideration during our SD evaluation.

We use JIRA for projects with our clients. We esimate the issue in JIRA where the client can accept the estimation (psuhing it truth the workflow). This is issential functionality for us to start using Service Desk instead, which has a far better customer experience then JIRA with all the options shown to our clients.

@Jon Leiberman - I agree entirely. It doesn't look good to have a more fully featured product being waved in front of our noses without giving customers the ability to benefit from those features too. It's concerning as to how much time is being spent on customising the product for their own in house use vs use for customers, particularly when it takes so long to implement highly voted for features into the product.

Customer should definitely be able to resolve the issue – it's just core functionality

Sorry If I came off the wrong way.
I accept it's a new product and that we're early adopters.
My point was that the only reference implementation one can see is the use of SD by Atlassian.
That implementation has multiple features that are not available to paying customers – which you don't find out until you're way down the roll-out road. That part is bad behaviour.

I'm just speculating here but it seems obvious this isn't being implemented because of the new licensing mechanism that's being used; service agents. The original licensing mechanism was similar to the other add-ons which made it cost prohibitive for many companies (for instance if there are 5000 users but only 10 people transitioning issues). To address this they added a Service Agent role that can transition issues (so you'd only have to pay for 10 users instead of 5000). The fall-out of this is that you can't allow users to transitions issues from the portal if they aren't service agents because then it would be a loop hole in their licensing (a service agent could transition tickets from the portal instead of full JIRA). So, adding a band-aid they are proposing adding pre-determined workflow transitions so they can control which Roles can execute them thus not opening a loop hole.

tl;dr: this feature relates directly to the JIRA Service Desk licensing mechanism and probably won't get implemented the way ya'll are asking for unless they change the way the tool is licensed.

It seems there are many pretty fundamental features that prevent the product being rolled out to customers. Our biggest one is the lack of focus on email rather than portal ticket management. Plain text email is not an option (which for blind users is a necessity), nor is email customisation, and the main killer for us is there is no way to CC other people into emails which are then created as tickets, and for those people to be involved in the ticket without having a user account in JIRA/SD (in other words, we need it to behave like normal email correspondence).

It is frustrating, but the product is in it's early stages. I think a lot of the issues stem from lack of observation of competing products and their fundamental features, not enough user feedback done prior to the product being released, and the fact that it's really just an add-on when it should be it's own stand alone product as there is too much conflict between JIRA and SD and other add-ons and SD.

Just my two pence...

We feel your pain. We did roll out JSD today and will stick to it, hoping Atlassian is shwoing us some love, but it's a real bummer they
didn't implement such critical and important features from the go. Let's wait and hope for the best.
I know, this might not be the ideal solution for everyone, if at all

The issue I have is that we evaluated Atlassian's implementation of Service Desk in order to make a decision to roll it out.

So we have spent money deploying this based on a product representation which is not accurate.

We should receive a significant discount based on degraded functionality. We can't use one of our Desks at all without this functionality. We didn't know that until we started roll out and had to pull it back.

Months? Try decades... https://jira.atlassian.com/issues/?jql=project%20%3D%20JRA%20AND%20resolution%20is%20empty%20ORDER%20BY%20created%20ASC%2C%20resolution%20ASC

For example, this highly voted (1649) feature is almost 11 years old with no resolution: https://jira.atlassian.com/browse/JRA-3821

I had the same response when I raised a ticket about it a few months ago.

What irritates me about it is that Atlassian clearly see that Service Desk functionality is lacking, so therefore add the functionality in for themselves to use, but when customer repeatedly ask for these features, nothing happens for months on end. Adding options to the portal for customers to have more control over their tickets should be fundamental to the user experience of the portal.

Exactly my point.
I too pointed this out to Atlassian support.
One would assume the Service Desk used by Atlassian is the same you can by from them!

Furthermore, Atlassian is prioritizing the issues based on what users want, and this is done by choosing the ones with the most votes.
Looking at this query in their own JIRA instance, then I would expect to see this issue in the next release:
https://jira.atlassian.com/issues/?jql=issue%20in%20votedIssues()%20AND%20resolution%20%3D%20EMPTY%20order%20by%20votes%20desc
JSD-40 is no. 8 in the list and no. 1 if you only look at issues for the JSD project.

Hi,
please deliver this:

• Escalation of a request - allowing the customer to escalate this request when it is becoming critical, or their needs are not being met.
• Closing a request - allowing the customer to close off the request when it is finally resolved, or when they no longer require that request.
• Reopening a request - the customer can come back to a closed request and mark it re-open it.

I just raised the ticket asking how to configure it, seeing the buttons on your service desk and the response is - this is not a part of the product now. What?

I expect that fixes which your team use in production to make the system more usable should exist at least as workarounds for customers also.

Why not to incorporate your own fixes? This is what I have got from your support personnel today:
The ServiceDesk that we used for our support system is heavily customized for our customer usability

This thread has been going on for a long time and has been ignored for the most part by Atlassian. Maybe your prod will help.

Good question, I really hope we're able to enable these functions somehow. Atlassian way too often seem to forget what listening to their loyal and well paying customer base means...

Huh, why is this functionality present in Atlassian's own Service Desk (which also runs on JIRA ServiceDesk) but not in the end users' version?!

Our organization has an urgent need for our Service Desk "Customers" to be able to change the workflow status of their issues.

The good thing is we on this thread agree with you , Pedro. The problem is we cannot seem to get Atlassian to agree. If they do, we have not heard it yet.

I am really commited with the KISS principles and always try to do things as simple as possible, but I think that allowing customers to close or reopen their issues is a must. Apart from ITIL recommendations I think this is just logical.

I totally echo "Ben Bazian" comments.

BTW Atlassian released JSD 2.2 and if you look at the bug fixes and their corresponding votes, https://confluence.atlassian.com/display/SERVICEDESK/Issues+resolved+in+JIRA+Service+Desk+2.2 it's wierd they are still picking up low hanging fruits.

It appears they are more concerned about the looks and feel when the functionality is in doldrums, what an irony.

@Manuel Borja, IMHO we got the frame of the house without any of the internal plumbing. What we are asking for is not an add-on feature. It is a basic feature like the plumbing. I have no issue with specialized add-ons. I do have a problem with paying extra for basic functionality.

Some products in the market are like a big house. So you have to buy the big house. The problem is that maybe you just use the bathroom and one room but you payed for the whole house. Atlassian approach is the opposite and I think it is good. You can buy the bathroom and the room. If we compare the price of JSD + plugin against the price of competitor products, maybe we will opt for JSD + plugin. You buy in 15 minutes, implement in some days and you get years of awesome features. Just my opinion

Maybe Atlassian should just but Service Pack for JIRA Service Desk and incorporate it. As I have stated earlier, I am tired of purchasing all these add-ons to make the product work. I guess next time I buy a car I may have to buy the tires separately.

It looks like we have one more member to our disgruntled party.

We sympathize with you Rasmus, if you look at all our past comments we have been pressing Atlassian to justify this limitation and unfortunately the last response is on the description of this Jira.

BTW we are still in dark when that small subset feature would get implemented though...it's totally frustrating.

As per Atlassian,

In terms of timing, unfortunately we cannot commit to a specific timeline for delivery at this stage.

Atlassian, can you please advise on how to get this prioritized ?

Thank you for sharing Service Pack for JIRA Service Desk.
However now I just feel evenmore cheated by Atlassian.
What is being provided in this addon is exactly what my business need for making the Service Desk perfect as a support tool, and I can also see that Atlassian support is using this plugin (just try to raise a support case).
So to me it also looks like Atlassian knows this is missing, but instead they just leave it up to an external developer group which profit on the missing feature.
This means my JSD will become 1000$ more expensive, if I want these features... sick!

Hello All
I do not know Atlassian actions. but for those who have not yet had the opportunity to check news in our Service Pack for JIRA Service Desk plugin, I'm glad to inform that we already added Screens on Transitions for Customers. We built it from scratch so it is clear and simple, just as its configuration.

Being that I just got pinged by this thread I guess I would question if there are any updates on the next release and if any of the comments here will be incorporated?

Edwin,

Thanks for the response. It is about time that Atlassian acknowledged this thread. in addition to what you put as needs I would add 2 more items.

1. In service desk you cannot @ mention someone in the ticket.
2. Unable to see attachments on a ticket that are added through the regular Jira in the SD dialog.

When you mention these items are you stating that Atlassian will be adding these or are you just positing the question? If yes, is there any estimate for when these items can be added?

-Ben

First of all:
We need to be able to decide per service desk project if we enable a specific state / transition option or not (to be able to keep it simple). All or nothing won't be acceptable because we won't need in any case all states.

Do you have other use cases that you are seeking to solve with this request? If so, what is it?

Next to

• Escalation of a request - allowing the customer to escalate this request when it is becoming critical, or their needs are not being met.
• Closing a request - allowing the customer to close off the request when it is finally resolved, or when they no longer require that request.
• Reopening a request - the customer can come back to a closed request and mark it re-open it.

• deferred / shelved / on-hold
  • We agree with the customer that there is currently no quick solution for that
  • But it's import to keep this issue on the "radar"
  • Therefore we need to have it as part of the reporting, but not in the state "open" or "closed" - a state like "open service request with no short term solution"
    
    
• ping service agent / "anybody at home?"
  • Usually customer writes a sentence like "Any status updates"? This won't be an escalation, but a friendly reminder.

What information specifically do you need to capture for that "transition"?

@Edwin: Not clear - would you please give us an example?

In terms of timing, unfortunately we cannot commit to a specific timeline for delivery at this stage.

No comment - except: either share your own dog food or provide the Service Pack (arrange an agreement with the guys) for the existing customer base for free until you provide the final solution.

Thanks Edwin for taking your time out to comment on this ticket, finally some traction atleast.

Totally echo "Atlassian Doesn't Care" comments and I have few more to add in regard to Edwin's comments

one of our goals has always been to minimise the complexity for both customers - as well as administrators who need to set up and maintain the service desk experience.

Well if we can setup and manage the complexity why would Atlassian worry about it. You guys already provide workflow transistions/customizations in Jira, so why is this sudden scare of complexity.

One key challenge we have had with this feature is the additional complexity that workflow transitions bring when included in the customer portal.

So why do you guys have that on your support portal ? can you please care to explain. Exactly in the same sentiments we also like to empower our end customers to have additional options apart from only comments. What if they want to put that ticket "On Hold" or they are not interested with the ticket anymore and just "Close it"

Since transitions can also involve additional screens and fields, we need to ensure that this experience did not undermine the portal's goal to keep the language of the portal simple for customers, or introduce significant additional overhead for administrators to configure that "translation".

We as admins don't mind this additional overhead of configuring the "transistion" . If the Service pack plugin guys can do it, I don't understand why you as Product owners can't implement this functionality.

Rather than building a generic capability to support workflow transitions, our intention moving forward is to support the key, specific use cases that we are identifying from you, and to solve them in a more targeted, optimised approach.

Can you guys do your own dog food ? why do you have those options on your support portal and don't provide to Plugin users. This is dual mentality IMO.

Do you have other use cases that you are seeking to solve with this request? If so, what is it? What information specifically do you need to capture for that "transition"?

we need options for "Putting On Hold" / Freeze .

In terms of timing, unfortunately we cannot commit to a specific timeline for delivery at this stage.

This is unfortunate that even after so many votes/comments there is no way to get this prioritized. The only bottom line that we read it here is Atlassian doens't care anymore about it's users and that's the sad story here.

Edwin: Those 3 buttons would resolve everything I'm looking to do with Service Desk at the moment, however presumably these buttons would just be invoking a transition ('Close', 'Reopen') so we'd still need to map a transition ID to those buttons? If that's the case, as the user above suggests it'd be great to be able to add/remove buttons and just have them take the transition name that they're mapped to so we could create new buttons if required.

I appreciate the desire to keep things simple, but I'd never turn my nose up at the offer of increased flexibility - either way VERY keen for this functionality, even if it does have limitations what you proposed would be a huge win!

Edwin: If presenting customers with new fields during a transition screen is the concern, could you allow us to add our own transitions, so long as there is no transition screen, or so long as it uses a blank transition screen (comment only)? With Jira, we were given the power to decide what was too complicated for our users, but with JSD, you seem to have taken the opposite approach and are deciding for us.

A use case we have is that when the customer updates the ticket, we want the status to transition from "Waiting For Customer" to "Investigating." The way JSD is now, the only way we can do this is to set up an auto-transition listener. The problem with this is that the transition happens after the customer has updated the ticket, so in the JSD portal, their ticket still shows "Waiting For Customer" until they reload the page, which they're very unlikely to do. They're left wonder why it's still waiting for them, when they just updated it, which is confusing.

I am getting a lot of pressure from above to make a final decision on this. I can't in my right mind plunk down a chunk of cash on a product I find to be deficient and have no idea what the future plans are. Thanks for sending something to the CEO but I would not hold my breath waiting for a response at this point.

I have now dropped a note to the Atlassian CEOs so lets see, if that can get their attention at least. I know I'm being too optimistic here but I'm not going to giving up either.

I feel like we are all waiting for Godot.

I put in a ticket on this to see what I would hear. Nothing other than some mumbo jumbo about that it is a product in development. No clue as to what the future brings. I find it a bit mind boggling that there is no comment from Atlassian.

Thanks @Piotr Mazij for your offer, unfortunately that does not tempt me enough.

We need you guys at Intenso to work at Atlassian and build an basic functionality in an expensive high profile product like JSD. As everyone else mentioned on this thread, I cannot justify the purchase of this plugin to my management to get a basic functionality working/started.

I know your plugin offers much more than a fix, but to benefit those features we will have to get JSD working in the first place.

If you guys at Intenso don't mind, I will throw in my 2 cents here. If you guys can provide this functionality alone as free in your plugin and charge for the rest and maybe after 1 year charge everything. Assuming Atlassian will address this on rapid pace as they are currently showing so far. So when users get this working, they might appreciate other functionalities in the plugin and opt to purchase and can also justify their managements on the value add here. Also it builds a confidence in the brand/vendor, this has been my experience so far. It's like the "whatsapp" approach.

PS : Irrespective of your consideration, I still appreciate you guys for the work in the plugin.

OMG, I ignored Atlassian totally...or they doing that to us ?

Can someone at Atlassian please say "Hi" at least, that would cheer us up here.

This functionality already exists in the Atlasssian service desk https://support.atlassian.com/. We would like to extend this feature to our customers as well.

I think the license priceses are high enough that we can request such a thing as a basic feature.
Additional is to say, that on the service desk https://support.atlassian.com/ this funtionality exists, so atalssian by itself knows how important such a feature is.

I would buy this product today if this feature was in the base product. Having to buy a separate plug-in does not work for me.

cmauro and madhusudhan.matrubhai - you (as one of the few) are facing the problem with blank Customer portal. Can you contact us at plugins@intenso.pl or login directly on https://intenso.atlassian.net/servicedesk/customer/portals and create a support task for the problem? As a exchange for help in solving the problem we can give you an extra pricing offer.

Our issue is the pricing model gets very expensive as you grow past 100 users. The way the licensing works you also need to pay at that tier even if you are using an add in (like Agile, etc) that only a small subset are using. I am tired of all these pay for add ons. I feel like a traveler that needs to pay extra to bring a bag on board. Next we will have to pay extra for a pilot.

That said, the limitations for the "customer" are too great for the product to be viable. If I do not hear something soon from Atalssian I will start to look at some of the open source systems that are out there. I believe there are several viable alternatives.

Has anyone tried Service Pack for JIRA Service Desk for the time being?

I know it is not ideal that such an important feature isn't in the core of JIRA Service Desk and being expected to pay more for a plugin is a bit ridiculous....

However,
If it is a show-blocker for your organization, perhaps forking out the $800 to $1500 for a 250 to 10,000+ license is a sacrifice worth paying...

As Atlassian has somewhat gained a track record for themselves when it comes to completely ignoring even the top ten most requested/voted issues on most of their product line and sadly I do not see this issue being resolved anytime soon

I second on Madhusudhan comment also. We have disabled the plugin until it solve visibility problems on the portal.

Awesome news! As we put a lot of efforts in development, we can finally say, that we have a working solution for workflow transitions in Customer Portal for Customers. No more "undefined" list and not working links for your customers around the world. Check out on Marketplace for "Service Pack for Jira Service Desk" ( version 2.0.0 for JIRA Server 6.0 - 6.3.10) by InTENSO and give us some feedback.

I second on Madhusudhan comment. We are not going with the service desk because of those limitations the whole solution is useless.

I echo these remarks from Madhusudhan.Matrubhai. This is pretty frustrating.

is anyone at Altassian looking at this thread, can you please comment on the dates so that we can plan our roll out and end this suspense.
If you guys still expecting more votes to expedite, please let us know.

The one thing that surprises me is that JSD is not an open source project and we pay top dollars to get that and yet we have to wait on votes for bug fixes/suggestion to get the attention.

Same here, please inform us!

Kind of a big deal to us, too. We need this ability, Atlassian

Thanks!

Anyone have any idea when the next release is scheduled for? Would also be nice to know what is planned for the release.

I see that too. It would be nice if someone would chime in to let us know what really is the plan.

Did anyone else notice ? the Jira is in "To-Do" status which means Atlassian is thinking about it, at-last some traction on this important feature.

Looking forward when it moves into "In progress" and "Done" status.

Thanks Atlassian for hearing into our rants and finally a glimmer of hope.

BTW can we have an ETA here please ?

I have not gotten the plugin to work at all for me- and have a very, very lengthy email chain with inTENSO on trying to get it to work. It will not read conditions properly, nor will it run the most transitions- only re-opening a case works for me. I can't get close case, or reply to agent working- Even with 0 conditions and validators.

Edit: I am not using Service Desk 2.0, but version 1.2.7

2nd Edit- I also want to say how good their customer service is. Even though I have had many issues, their support has been really, really good, and I can see that they want to fix the issues. I have confidence that the issues I am facing will be resolved very soon.

Madhusudhan, thank you for good word.
Yes, we, InTENSO, have that buttons functionality on our plugin, but I must say that it does not work proper for new user group Customers, created by Atlassian for JSD 2.0.x (long list of "undefined" transitions is visible under the proper transitions list). I must admit that JSD 2.0.x is kind of a tricky on its solutions, even for us, so currently there is no support for JSD 2.0.3. Anyway, feel free to try the trial since there are few more useful features.
P.S. About the Ferrari - I think that even if provided with the stick, any of us could find an idea to modify it for own needs.

I am tired of paying for all these plugins to make Jira do what it should do. This should be a basic requirement. I have a few plugins that are used buy only a few people but based on how the licensing works I have to buy at a much higher tier. Not fair. As for response from Atlassian, I tried to get this info on a ticket I had earlier and was not able to get any idea as to what the plan is.

"About our Support Portal, what we use is in fact a highly customized JIRA, not Service Desk, that's why it has so many different functionalities."
So it's seem the ServiceDesk is not even enough good for them.
Not good.

Not true:
https://support.atlassian.com/servicedesk/customer/portal/3
JIRA Service Desk (2.0.2)

Emre,

I'm currently evaluating that plugin and is doing a good job on what it says except when we hit a known bug which spoiled our first experience.

After plugin upgrading, Customer Portal page is blank. Workaround: Disable plugin, go to Customer Portal, enable plugin.

So far I like the plugin except that I'm worried how will I convince my management to buy this additional plugin after buying an expensive Ferrari which doesn't provide a stick to change the gear.

By the way, there is this plugin in the marketplace that claims to add workflow transition buttons into customer portal.
https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.jsd-extender

Is there anyone who used it in production? Any feedback on its capabilities and performance ?

Excellent point. Regardless of the general feedback from the contributors here, we need a statement from Atlassian as to whether this feature is something that will be considered in a future release. From my perspective, this issue is sufficient for me to not consider using the ServiceDesk product so I would appreciate an official view.

That totally explains that they don't do their own dog food as they claim it everywhere else.

This ticket is been open for more than a year and still there has been no update from Atlassian if they are ever going to work on this or not. It's not that they have to build a new solution when they already have this working on their support portal.

Maybe Service desk was a bad experiment and sad we got involved in it.

Emre,

I asked the question to support why the functionality is available in their support site and not in Service Desk. I got the following answer:

"About our Support Portal, what we use is in fact a highly customized JIRA, not Service Desk, that's why it has so many different functionalities."

So it's seem the ServiceDesk is not even enough good for them.

Not good.

Emre,

I hear you loud and clear. I have a vital decision to make. We are out of licenses and the next tier is super cost prohibitive, a 300% bump. May be time to look at what else is on the market?

I fear Atlassian already decided not to provide this (vital) feature in JSD but since it is present in Atlassian's own service desk portal, they are thinking of a way to sell this decision to us. If otherwise, why the silence ?

Is there any update from Atlassian as to where the product is going? This thread will go on forever but we are not being told whether any of this will be supported. The other issue I have with the customer interface is the inability to @ mentions someone in a ticket.

Alex,

We to have the same concern. We are needing to migrate to 2.0 because of licensing but the short comings of 2.0 are glaring. For us a major part is that users cannot close their own tickets or reopen in case of need. Any word from Atlassian on what the next additions to the Service Desk will be would be appreciated.

We are in the process to pass our Helpdesk to Jira ServiceDesk on demande and Atlassian force us to go with the 2.0 as the old one is not available. What I do not understand is why we cannot add workflow for customer interaction with support, in the customer portal, as it is the main interface for the customer.

This should be a part of the basic solution. I cannot give the ability to my customer to close their issues themselve if not required, it have to be an agent do it. This functionnalty seem to be available on the atlassian support page but we cannot have access to it.

I hope Atlassian will change it soon.

As per the earlier comment

Edward Zhang [Atlassian] added a comment - 21/Nov/13 4:21 PM. We currently do not have workflow transitions in the Customer Portal. https://support.atlassian.com has custom modifications that do not reflect the Service Desk product. Those modifications are specific to that instance only.

Which means they are not using the default product which is a bit misguiding and why don't they realize that teams out there also will need this basic customization incorporated wherein it provides the additional workflow actions available.

We are not asking for any fancy stuff here, all we need is the existing workflow actions available on the JSD.

Also I wonder why did they not incorporate this customization in the existing product ever after so many releases.

They are using JSD, but they're running version 1.2.4, rather than 2.0, for some reason. JSD 2.0 doesn't seem ready for prime time, IMO.
https://support.atlassian.com/servicedesk/customer/sds

It's not fair that Atlassian categorizes this as a suggestion, instead this should have been a Bug, IMO. This is such a show stopper for all those teams/project that use a customized workflow.

It's so disappointing that Atlassian has been sitting on this for more than a year and they continue to sell this product in all it's fan fare and they don't do their own dog food as they claim everywhere else. (Reference to not using JSD on their support portal)

Can someone from Atlassian throw some light if they plan to ever fix this and an ETA.

Thanks

thx Ben!

I was referring to the new 2.0 agent based version. That is what is stopping me from upgrading to the new model at this time.