1- Customers enters their requests in SD
2- The agent verifies if this is a bug. If required the agent collaborate with developers (https://www.atlassian.com/blog/archives/collaborate-developers-using-jira-service-desk)
3- If this is a bug, the agent creates a linked issue (which is a bug in JIRA Software in the relevant project) from the initial request in SD. Both issues are linked back and forth from JIRA to SD and vice-versa. Note that when you create a linked issue, most information is copied from SD to JIRA.
4- We added an automation rule in SD, when the JIRA issue is closed, a new comment is automatically added to the original request and an email is sent to the agent.
5- The agent can close the SD request according to the process.
Unfortunately, the blog article referenced is sadly out of date. There are no more collaberators or agents in Service Desk. So are the developers then users, or developers, or lead developer, or service desk team? According to this article you add both your developers and your agents to Service Desk Users and agents are differentiated from developers by whether they have a service desk license tied to their user account.
You're right, the roles do not exist anymore.
We added developers to the "Service Desk Team" without giving them a licence of SD. So they contribute when required, but are not agents per se. (Using the Admin account: Users and Roles of SD)
The agent directly addresses them using the @name using the comments section, with the "internal" type. This isn't possible if your developers are not part of the "Service Desk Team"
Developers reply the same way.
Hope this helps.
Samir, please tell me if I stray too far from the subject.
If you choose to have separate Service desk and development projects, how do you setup seamless integration between them.
Example we have projects for our core products and projects per customer, as the customers use of core products might yield additional development as apps or other features.
We create a service desk project to handle support. When a bug is detected by our support team, we wish them to create an issue (bug) in the related development project with a link to the original support issue.
How can we accomplish this in a one step operation ?
So far I can do Clone > move > link. Which is a 3 step operation. Where creating a new issue is a one step operation.
That doesn't exactly give me a benefit of using JIRA Service Desk over a competing product as RT by BestPratical.
Tommy, apologies for not responding sooner. For us, we typically won't clone an issue per se, since it's typically in the words of a customer and therefore wouldn't necessarily translate into technical requirements we prefer in our Software JIRA project. So, we'll typically invite developers to collaborate on the customer issue in Service Desk. If it warrants a software modification, that developer can create an issue in the Software project and link to the Service Desk Request. We haven't found a better way to do this yet.
i have followed this thread and can't get an answer for my request and question.
I have investigated a development process for optimize the integration between JIRA and service desk..
We want our customers (Service desk users), to both follow the SD status AND the linked JIRA case status, if there is a JIRA case linked.
Then the customers can follow our internal work process and don't need to ask us for an update on their support case.
I have attached a picture. The green boxes show a picture where the customer can see both the SD status and linked JIRA status.
So my big question is... Can this scenario be possible?
This is not currently possible. JSD customer do not have access to JSW notifications. You might try something like using Scriptrunner to update a custom field in JSD that would key JSD Automation. To achieve what you propose in the image you are cracking open the code I expect. I will qualify this with AFAIK. :-)
So we essentially have a Software Development project type that the team is using to track everyday software dev issues and track ongoing development of the product.
I'd like to have our customers be able to enter tickets into that system, have agents work them, and create development bugs directly in the Software Development project. Is this possible, or do I need to create 2 different projects (one for Software Dev, the other for Svc Desk)?
As the customer can only see issues tracked by them with the Service Desk Request Type, the customer won't be able to see issues created on this same Service Desk project created by your development team. So, you can chose the options who better fulfil your company organization.
Just to resurrect this thread, I don't understand why Atlassian seem to have no interest in making this workflow work. In many software companies, the helpdesk and development teams are separate entities, it is the responsibility of analysts on the helpdesk/support team to push bugs through to the development team.
Currently there is no streamlined way to do this, having the developer manually adding a ticket and cutting and pasting the details across isn't very efficient or accurate.
what info is having to be cut and pasted and why? Our agents use Create Linked Issue which basically clones the SD ticket into the SW project of choice. This is a 5sec process for us. The fact that they are linked allows the assignee of SD and SW tickets to have access to further comments. I do wish that there was a way to add an Internal comment into the SD via the linked issue but the reality is that since the SD agent created the SW ticket they would receive notifications of updates and the SW developer can be added as watcher to the SD ticket if desired.
Regardless, if there are specific behaviors desired then you may want to open a Suggestion for JSD with Atlassian. In fact wouldn't be surprised if there is already be something on this.
Thanks for your input here Jack, very helpful.
I'm in a similar situation, however would like to clarify:
If a customer submits a ticket, and one of our agent picks it up in SD Project, creates a linked task then assigns it to a developer over in an Internal Project:
To give you some scope on why we're asking - our biggest 3 challenges are:
Can we set up JSD so that the customer - a small digital media / analytics team - can:
@Jack Brickey Thanks for the response.
Bummer about the customer not seeing the internal stuff. We have an odd setup where our client wants to see the progress of our sprints and releases, however we need to be careful of what information they see (like time tracking. etc).
Good to know that we can add the devs as an Agent if need be to at least have that cross-project collaboration.
I'll have a look into scriptrunner to see if it can save us some time in creating / commenting on tasks.
you don't need to add the developers as agents to collaborate on the JSD tickets but if you want them to make public comments they need to be agents. That cost money though. You can always have the Agent take the internal dev comment, wordsmith and make public. Generally that is preferred in my experience to control the messaging to the customer.
Just released (afaict) is this: https://confluence.atlassian.com/servicedeskserver/collaborate-with-other-jira-teams-on-jira-service-desk-issues-950813501.html
It's reasonably helpful and makes it clear that with the addition of the Browse Project and Comment Creation permission (we assign it to a role, rather than the application-side logged in users) your non-front line staff can view, follow, and contribute to internal commentary on a JSD issue. Linked issues also get notifications.
The Jira Service Desk marketing team is working on a guide to help new Atlassian customers switch from email to JSD and we'd love to hear from you! Please share: - What made you realize that i...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs