You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hello, I'm a beginner Atlassian. I ask you guys for help.
Our Atlassian product line includes:
Jira SM : Agent
Jira SW: engineer
We want Jira SM to respond first to issues coming through multiple channels, and Jira SW to respond secondarily.
So, the issue generated in Jira SM is generated in the same way in Jira SW, and when the status of the issue is changed, I want to apply the same to Jira SM and Jira SW.
I'm researching to implement it as an Automation function, but there are many difficulties, so i ask the community for help.
I would appreciate a lot of advice.
Welcome to the Atlassian Community!
Start by training your SMs to use the "create linked issue" function in the service desk. This lets them copy the issue behind a request into a development project.
Once they're doing that, you can set up Automations that can watch for change on the linked development issue, and push transition updates back into the Service issue.
@가나다라 hello. Upon reading your question I think a bi-directional integration between the two systems is what you need. With this type of connection between the two systems whenever you create an incident (as in your use case) in one of them it will automatically be created in the other, too. Also, any change/update in any of the fields will be present in the other.
How do you plan to achieve the connection between Jira SM & Jira SW? If you're open to using a connector - check out ZigiOps. It connects the systems in question bi-directionally and fast, no additional coding needed. It allows the transfer of default fields + custom fields between the systems and syncs them in real-time. ZigiOps reads the schema dynamically so you can transfer any of the fields available in the system. The tool can also be customized to fit your current integration needs. Give it a look and even book a demo to see how it handles the integration in question.
@[deleted] hi there. Feel free to also take a look at ZigiOps. It helps establish a two-way connection between your systems and keep them up to date in real-time (syncing all the fields you want). You can tailor it according to your needs - which field to populate, sync, transfer, etc.
This is Dhiren from Exalate.
Exalate, provides a fully bi-directional synchronization between Jira(Cloud,Server,Data Center) and Jira(Cloud,Server,Data Center) among other ITSM systems that is fully customizable. It is easy to set up and the entire customization can be configured using a no-code interface.
You can even integrate between Jira Software, Jira Service Management (Service Desk) to achieve your integration requirements.
If you would like to see a customized demo of the product in action, feel free to book a slot with us.
Backbone can help you link and synchronize any activity on your Jira SM with Jira SW. So if you create a Jira issue on SM, it will automatically be created on SW. This would also include real-time updating of the issue status, comments, components, custom fields, and every other Jira data across different projects.
If you are interested, please get back to me at firstname.lastname@example.org and we can give you a free demo of the app.
Similar question; we want to have a DevOps team working on an incident (or service request or st. change request for that matter) and we want the JIRA SM issue type 'incident' to be transferred to a Jira SW project but keeping the Jira SM issue type 'incident'. The goals is to have both Epics, Users Stories, Bugs visible on the DevOps team board together with he Incident/Service Requests/St.Change Jira SM issue types in order to work fully DevOps!
If we use the 'move' function it will demand the issue type to be changed to either Epic, User Story or Bug... (default Jira SW issue types only)
Any suggestion are welcome!
welcome to the Atlassian Community.
I'm not sure if I understand you correctly, so here are some ways how I could interpret your question:
I can also try to give more context when you reply which direction is more interesting to you.
PS: As an advise for the future, I would ask a new question instead of jumping on an existing one - this has also a better visibility and therefore higher chance that people reply to you.
Thanks for your swift reply! Your are exactly addressing our question as we wanted to understand all possible scenarios which you have clearly pointed out.
The board filter makes sense in a way, to create one overview for a team to oversee both DEV and OPS workload. But we also want them to take ownership of a ticket (incident, service request or st. change).
We did already experiment with the 'move' option, but indeed the downside is you lose everything in JIRA SM when moving. Which makes sense in a way, but is not what we want to do.
So probably option 3 is the best solution for our goal to have a sync between the two.
The other possibility we have explored is to have a ticket (incident, service request or st. change) created in JIRA SM and then use 'link issue' to create a issue type on a teams JIRA SW board (like sending a task to a team in ServiceNow). From that point onwards both are linked together and people using JIRA SM can see the updates in the JIRA SW linked item. The downside of that is it does not copy over all items (perhaps needs some adjustment to make that possible). Another downside is that if the team user using JIRA SW does not have a JIRA SM license, they will not be able to see the original ticket created in JIRA SM (which might not be necessary so limited impact).
What's your view on the latter?
You're right, @[deleted]
Linked issues would indeed also be an alternative. This way, there are also two separate tickets where people can work in. I'd probably think about the decision like this:
I hope that helps,