Jira and Confluence have probably come across your radar if you’re looking to help your company move beyond an old system like managing requests by email or passing around Word documents. You want to change the culture to be more agile, to use modern techniques for workflow management and project management. Both Jira and Confluence are great to keep track of what you are working on, the status of them, and for your stakeholders to get an at-a-glance update.
But why should you use one over the other? Or should you use both Jira and Confluence? Let’s cover the basic differences and similarities of the tools and explain why and how your team should use them.
What this guide covers
What is the difference between Jira and Confluence?
Jira is a task management solution that allows you to track and manage issues throughout the lifecycle of each task. Jira can help with everything from software development to incident management or even HR processes, whereas Confluence is a wiki-based content management tool that allows you create and organize information collaboratively. Organizations commonly use Confluence for knowledge bases, product documentation, or intranets. Both are inspired by agile methodologies and are built around collaboration, but where Jira is great at tracking the status of individual tasks in standardized views, Confluence is great at bringing broader information together with an emphasis on visual presentation and creativity.
Let’s take a quick look at the major features of Jira and Confluence.
Features
Jira
Jira comes in a 3 main flavors: Jira Software, Jira Service Management, and Jira Work Management. They all share core components and logic and allow you track issues, but each is geared towards specific needs or teams.
Jira Software: Powerful and flexible, Jira Software is built for software teams using agile methodologies, and includes functionalities for sprint planning, bug tracking, and release management. Jira Software allows you to track affect and fix versions, plan epics and user stories, and analyze your sprint burn down.
Jira Service Management: The ITSM solution from Atlassian, Jira Service Management is a support desk for customers or employees to raise requests. Agents can then manage requests in queues and make sure everyone gets the help they need. JSM provides out of the box configurations for IT service management like service requests, incident management, and change management, but can also be used for facilities management, HR, or even legal teams that need to manage incoming requests.
Jira Work Management: Jira made for business teams: Jira Work Management includes calendar views, Excel-like list views, and basic forms so business teams like marketing, HR, or sales can track tasks in Jira with features adapted to their needs. JWM is only offered on Cloud, though on premise users have a similar experience with Jira Core.
Confluence
Confluence provides your organization a place to organize ideas, content, and files for all your activities. Since Confluence takes care of version control, you can treat it as your one source of truth and rest assured it will always be the up to date version. Favorite features include the search power, content organization and permission management, and the easy WYSIWYG editor.
Limitations
Jira: If you are looking for more traditional project management software, perhaps that includes project cost tracking, Jira wasn’t built for that (although there are apps on the Marketplace to add that kind of functionality). Jira is really good at tracking and reporting on individual tasks, but for a broader vision of a project or version planning, it’s better to work in Confluence.
Confluence: Confluence does include the possibility to assign tasks, but tasks are either “To do” or “Done”. If you need to keep track of a more complex workflow, Jira is a better option. Similarly, if you need to track how much time was spent on a task, Jira is a better option than Confluence.
Pricing
Atlassian sets the price of both tools based on the number of users and is digressive, but Jira is a bit more expensive per user. You can adjust how many users have access to each tool so you only pay for what you need. Jira Service Management pricing is different because it’s based on the number of agents replying to requests (customers or employees creating the requests are free).
Get an estimate for how much it would cost your organization with the Atlassian Cloud pricing calculator
Don’t forget to budget for apps so you can customize Jira and Confluence for the specific needs of your organization.
Jira vs. Confluence: Comparison Chart
Cloud versions
| Feature | Jira | Confluence |
|---|---|---|
| Assigning tasks |  | |
| Workflow management | |  |
| Personal dashboard | | |
| Templates | | |
| Support desk | | |
| Knowledge management | | |
| Access control/permissions | | |
| Collaborating/commenting | | |
| Roadmap planning | Very detailed | Basic |
| Project management | | |
| Calendar view of tasks | Jira Work Management only | |
| External app integrations (AD, CRM, Google Drive…) | with apps | with apps |
| Time tracking | | |
| Native reporting | | Premium only |
Why use Jira and Confluence together?
By using Jira and Confluence together, you benefit from their complementarity: Jira to keep track of distinct tasks individuals need to work on, and Confluence share and organize all of the ideas, content, and files you collaborate on with your colleagues.
Single source of truth
By using collaborative tools that allow everyone on your team to create, update, and share information in real time, you’ll be able to treat Jira and Confluence as your single source of truth. Whether you need to know which bug fixes are in QA review, where the most up to date documentation pages are, or the roadmap for the marketing team, Jira and Confluence allow everyone to access the same information.
Break down communication barriers
Software developers may spend more time in Jira, and business teams more time in Confluence, but by integrating the tools, everyone can access the information they need from the rest of your organization. Instead of information siloed by team, everyone can access what they need. Imagine the flow of ideas when UX designers, Product managers, and Marketing can work from the same page, instead of sharing each update or comment separately.
Improve efficiency
When requirements are listed in Confluence, and linked to Jira issues, and those issues also link to product documentation in Confluence, there’s no searching for information or struggling to make tools talk to each other. Teams that use Jira and Confluence together are more efficient because they spend less time keeping track of work and more time on the work.
How to integrate Jira and Confluence
For Cloud users, integrating Jira and Confluence is automatic as soon as you have both products on the same site. If you only have Jira or Confluence, you can add another product is just a few steps:
Step 1: Open the Settings menu from next to your user icon on the top right of Jira or Confluence, and select Billing.
Step 2: Once in your Atlassian Admin, click on Products in the top menu (between Directory and Security).
Step 3: You will see the products you currently have. Click on “Add Product” and follow the set up wizard to add the additional product to your site.
If you are using Jira or Confluence on premise (Server or Data Center hosting), you will need to go to 
> General Configuration > Application links, Enter the URL of the application you want to link to, and configure with OAuth (with impersonation) authentication. Read Atlassian documentation for more details.
[vc_row][vc_column][vc_column_text css=”.vc_custom_1622193388776{border-top-width: 2px !important;border-right-width: 2px !important;border-bottom-width: 2px !important;border-left-width: 2px !important;padding-top: 20px !important;padding-right: 40px !important;padding-bottom: 20px !important;padding-left: 40px !important;background-color: #f5f5f5 !important;border-left-color: #f5f5f5 !important;border-right-color: #f5f5f5 !important;border-top-color: #f5f5f5 !important;border-bottom-color: #f5f5f5 !important;}”]
✅ Check out our guide on how to integrate Jira and Confluence
[/vc_column_text][/vc_column][/vc_row]
How to use Jira and Confluence together
A picture’s better than a thousand words, right? So here are two examples of how to use Jira and Confluence together for project management or requirements management.
Confluence and Jira for project management
Let’s take an example project you might be familiar with: migrating applications.
Many teams will start off with kick-off planning in Confluence, where you can take advantage of page templates like Project Plan, Meeting Notes, or DACI, tag everyone involved in the meeting, and start noting tasks, deadlines, and action items.
From there, you can create Jira issues for the tasks and assign them. If you are the Project Manager, you can track and share progress of the various tasks by using a filter to display all the issues related to the project on a Confluence page.
As the migration project continues, the team can use Confluence for functional specifications, technical documentation, and feedback on the migrated tool, with everyone on the team able to see, comment, and collaborate on those documents. Any files or assets needed can be added to each page, so team members don’t have to remember where to look on a shared drive. If configurations or features need to be reviewed once the application has been migrated, you can use a ‘Review’ status in your Jira workflow and assign the issue to a team member.
Jira and Confluence for requirements management
Create, share, get feedback, update, rinse and repeat: Jira and Confluence are the agile solution to requirements management throughout the life of your product development.
Confluence ships with a blueprint, or template, for requirements management, so you can get started right out of the gate. You can then solicit feedback and comments from multiple stakeholders, who can either comment the text directly, comment the page, or update it themselves (you can always check the page history to see the changes).
If you have customer interviews or other research that is useful background information, you can link those pages directly from your requirements management page.
As the requirements are detailed, you can start creating User Stories for them in Jira directly from Confluence by highlighting the text.
If you need to include wireframes, mockups, or prototypes on a Confluence page, there are multiple apps that allow you to do that so everyone can keep all your work together. Team members can even comment mock ups just like text or other images.
Confluence automatically creates a page summarizing the main details from all your requirements management pages if you use the blueprint, so you can see at a glance the progress of all your different projects.
Get your team on Jira and Confluence
You want an agile, modern solution for your team, and Jira and Confluence provide that. By using them together, you’ll get the most out of both tools and see the benefits: a single source of truth, breaking down communication barriers between teams, and improved efficiency. The whole really is more than the sum of the parts! Curious to learn some concrete examples of the different ways you can use Jira and Confluence together?
In 2020 Atlassian announced they are sunsetting their Server products to sharpen their focus as a Cloud-first company. While this change won’t happen overnight, and they are leaving up to three years for their Server community to make the switch to either their Cloud or their Data Center offering, planning a migration requires careful thoughts to evaluate options, choose the one that’s right for you and implement it. Rest assured, Elements has a plan to support you through this transition, no matter where you stand and where you want to go.
In this blog, we’ll review the changes timeline and share with you our commitments to our Server customers and resources to help you navigate these changes. Our goal is to give you visibility with regards to the future of our Jira and Confluence apps, so you have all the information you need to design your migration plan.
Summary of Atlassian’s announcement
In order to focus on its Cloud offering, Atlassian stopped selling new Server products starting February 2nd 2021 and will fully stop maintaining the Server products in February 2024. New apps sales for existing Server licenses won’t be possible after February 2023. This leaves Server customers up to three years to plan and execute their migration.
One important thing to note is that as of February 15, 2022 you will no longer be able to upgrade or downgrade user tiers for your Server products or apps.
Atlassian has put in place several mechanisms that will help you switch platform:
- Loyalty discounts for their products to help transitioning to Cloud or Data Center (decreasing over time to incentivize you to switch at the earliest possible date)
- Extended free trials for Cloud
- Multi-year contracts
We advise you to reach out to Atlassian or your Solution Partner for more information about pricing and how to take advantages of these mechanisms.
Navigating these changes
With significant changes, comes significant questions. We’ve gathered resources that answer the most prominent ones we’ve received over the past few days in the sections below.
Our commitments to our Server customers
We know these changes have a significant impact on our Server customers, and we’re here to help you through this transition. Here’s a summary of our commitments to you:
- Server: we will continue to offer support for our Server apps until the end of Atlassian’s support period in 2024.
- Data Center: we do offer a Data Center version of all our apps. This version offers the same features as your Server version and is frequently tested against scalability and security issues. We will continue to support and ship new features to our apps on this platform.
- Cloud: Over the past year, we’ve been working a lot on taking our flagship products to Cloud. We’re proud to say all of our apps now have a Cloud version. We know there’s currently a gap in functionality between our Server products and our Cloud apps. In the coming months, we’ll work on making sure the value you can get from our Cloud apps exceeds the one you currently get with our Server apps. We will also invest in easing the migration from our Server products to our Cloud apps.
Resources for our apps
We have created some resources to keep you updated of the key differences between the Cloud / Server & Data Center versions of our apps. These pages will be continuously updated with our apps status regarding Cloud:
Atlassian’s migration resources
Atlassian has created a lot of content to help their customers on their journey to Cloud or Data Center. We’ve curated a list of the resources we think are most useful:
| Cloud resources | Data Center resources |
|---|---|
| Cloud migration hub Claim your free Cloud migration trial Cloud roadmap Data residency information Security and compliance information Pre-migration checklists Jira Confluence Server to Cloud migration FAQ | Timeline of changes Data Center migration hub Data Center roadmap Migration guide Jira Confluence Simplified Data Center deployment (non clustered) |
We’re on this journey together
Over the past decade, over 2200 customers have put their trust in our Server apps. We’re very grateful for that and want to thank you for your continued support.
The Elements team is fully committed to making your path to Cloud or Data Center as seamless as possible. Feel free to contact our support team for any concerns that you might have: you can count on us to answer your questions, provide guidance, and offer 1:1 support throughout your journey to cloud.
We at Elements like a challenge, so naturally participating in Atlassian’s Codegeist is something we look forward to each year. What is Codegeist? It’s the annual developer contest that helps teams unleash their potential by building Atlassian apps. In 2020 we submitted beta versions of our Jira cloud apps Elements Connect as well as Elements Copy & Sync. We were in the starting blocks this spring, waiting for the 2021 contest. Finally this summer (for us in the northern hemisphere 😉 ) they announced it! Check out the Codegeist 2021 details and project gallery over on Devpost.
But this year it was all on Forge 😮 (okay we weren’t actually that surprised; Forge is the future of apps for Atlassian). Here’s the behind the scenes experience of our submissions SkillQuest and Office Manager.
What is Forge?
Forge is Atlassian’s new developer framework, and since it will probably be the main developer platform in the future for Atlassian apps, we actually didn’t wait for Codegeist to start to get our hands dirty. With some developers, we started “Forge Sessions”, a dedicated time to learn and explore Forge by creating apps with a real purpose. Once the Codegeist was announced, we figured it was a good opportunity to propose some of our most advanced prototypes.
Our experience developing on Forge
What we liked
Right away, we liked working with Forge because it is so fast to get a functioning app deployed on our Atlassian products. The Forge environment is really developer friendly (our thought is that non-developers are targeted by this framework). Also the fact you don’t have to worry about the infrastructure really gives you peace of mind. Forge provides Function as a Service (FaaS) to developers. All you need is to write a Javascript / Typescript function with your business logic inside, then register its name to your app manifest. Forge will automatically deploy it into an isolated FaaS environment.
What was frustrating
But we couldn’t help feeling frustrated by some lack of functionalities due to the framework being so recent. As an example, some cool locations like the Jira general pages or post installation pages are not available yet. Some new comers, like UI Kit (which allow you to build interfaces for your application) would require more components to address more common use cases. We also ran into several Forge APIs that don’t have a Typescript declaration (or are not completely typed) which can slow down development.
Even though Forge doesn’t contain all the features of is big brother, Atlassian Connect, the team is really reactive (with at least one release each two weeks) and some of the missing features are already listed on the Forge Roadmap.
Testing Forge Storage
During the process of creating an application with Forge, our plan was to not use an external backend (using a Cloud provider). Everything should be handled by Forge functions, in order to deeply test the possibilities of the framework and to quickly develop our prototypes. Note that it’s possible to build Atlassian Connect apps on Forge, to use feature of both frameworks, but it’s still in beta. This approach lead us to work heavily with a new feature: the Forge Storage, a place to store dictionaries of data, which are dedicated to our app and a tie to an Atlassian instance. Again, the Forge Storage API is recent and doesn’t provide a lot of advanced features (like advanced query or results sorting) but can be used anyway.
In the end, our Elements developers worked on 6 apps, and we submitted SkillQuest and Office Manager early September 2021. It was a bit tricky since the contest ran during our summer and some team members were on vacation, but we’re proud of what we were able to submit.
For anyone looking to give Forge a try, some knowledge of Javascript / Typescript and some basic concepts of Jira and Confluence are necessary to be able to create an app. It should be noted that the Atlassian community for Forge was really reactive and a big help for anyone developing on Forge.
What we learned along the way
The great thing about participating in Codegeist was that we learned just how fast you complete an app with Forge.
One of the most challenging features we worked on was the Office Manager office editor was the most complex part. We had to go back to trigonometric math and transformation matrix; that’s not something we do often when developing Jira add-ons!
Retrospectively, we wouldn’t do it the same way. It was really fun to do and a great opportunity to play with HTML Canvas, but unfortunately it’s now very complex to add some features to the map. It we had to redevelop the office editor, we’d check for third-party library first and if nothing match our need, develop by our own with maintainability as a priority.
For the future
At Elements, we will continue with our Forge sessions, and we want to explore the “Connect on Forge” app side to prepare a potential migration of our existing Atlassian Connect apps. We plan on utilizing what we learned through our participation in Codegeist by bringing everyone on our team up to speed on Forge. We’ve created a sample app developers create as an exercise so they familiarize themselves with all the features on Forge.
To learn Forge, our developers have to connect Jira to Cat as a Service so that cute cats are automatically added to new issues. The goal of the exercise is create an app with this structure that uses:
- main forge features like Forge Storage, Forge bridge and Forge API;
- and also Forge triggers to automatically generate a cat picture once the issue is created;
with an end result that looks like this.
You probably already use Jira and Confluence together, for example adding a link to a Confluence page to a Jira issue or creating a Jira issue by highlighting text on a Confluence page.
But what about creating a Confluence page from a Jira Cloud issue? We’re thrilled to share that it’s now possible with our new app for Jira Cloud: Elements Publish to Confluence.
Elements Publish to Confluence simplifies the process of creating a Confluence page directly from Jira, 0 scripting or webhooks required, and it can be set up in minutes for teams using Jira Software, Jira Service Management, or Jira Work Management.
Create a Confluence Page from Jira
Elements Publish to Confluence lets you design templates to publish issue data to Confluence as part of your team processes. Each recipe allows you to design a different page, specify where it will be created in Confluence, and from which Jira issues it can be used.
When creating your template, you can insert issue data, specify whether or not labels and attachments should be copied from Jira to the Confluence page, and also decide if you want a link added.
In Jira create Confluence page from template
It’s easy to set up a recipe in Elements Publish to Confluence.
Step 1: Define where the recipe will be available
Do you want to create a page for bug analysis? Make your recipe only available for bug issues. Need to publish issue details for a post-mortem? Set the issue type then the status to resolved (tip: you can trigger the recipe when the issue is resolved). Want to create a page for marketing campaign notes? Make the recipe only available in the Marketing project.
Step 2: Define where the page will be created
If we could read your mind, we would. But for now you need to chose the Confluence space and the parent page where you want the new page to be created.
You can also activate in the Target tab the option to automatically add a link to the Confluence page in your Jira issue.
Step 3: Design your page
Finally the good stuff!
The in-app text editor lets you configure the content and layout of your document. With the wysiwig editor, it’s easy to insert data from your Jira issue into your Confluence page, and you know what your page will look like. To provide a complete picture of what is in the Jira issue, you can also copy attachments and labels to your Confluence page.
Is your team already using Confluence templates, like the ones provided by Atlassian or maybe one you created? No worries, you can keep using them: you can inject Jira data into any existing Confluence template.
💡 Tip: set up the page title combining static text like “Bug analysis of:” with details from the issue like the summary or key. Your page title will be dynamically created each time the recipe is used.
Activate your recipe, and you’re ready!
Trigger Confluence page creation automatically from Jira with a post-function
Has your team forgotten to create and link the bug analysis/post-mortem/knowledge base article AGAIN?
Make it easy for everyone by adding a recipe as a post-function to a workflow transition. When Jira users transition the issue, the new page will automatically be created in Confluence. This is a perfect opportunity to use the issue summary to dynamically create the page title since users won’t be able to modify the page title when the recipe is triggered by a transition.
If you have several post-functions already added to your workflow transition, you may want to add a few seconds delay to the execution of the Elements Publish to Confluence recipe to optimize the performance of your instance.
Publish to Confluence: post-mortems, meeting notes, marketing campaigns & more
Elements Publish to Confluence can help lots of different teams that need to regularly create pages with details from Jira, no matter whether they are using Jira Software, Jira Service Management, or Jira Work Management. Here are some of our favorite use cases:
- Bug analysis: insert details from bugs raised on your support portal onto a Confluence page so team members can add details and analysis
- Post-mortem: add the recipe as a post-function to a workflow transition and automatically create a post-mortem in Confluence and insert details from your Jira issue when you transition the incident to closed
- User story details: insert details from the User story and Epic onto a pre-formated Confluence page to add details
- Release details: automatically generate a Confluence page with all the details from a release ticket when you transition it to done by adding the recipe as a post-function
- Knowledge Base article: apply labels from the Jira issue to your Confluence page and make information easily searchable
- Meeting notes: use the dynamic page title option to generate a page for notes based on the summary of the issue and activate the link option so meetings notes are easy to find from the issue
- Marketing campaign: insert all the campaign details and collaterals from your Jira issue onto a Confluence page and get started on the details of your marketing campaign
- Employee onboarding: new hire request received on Jira Work Management? Publish all the details on a Confluence page where the manager or team members can add details
- RFP process: Jira Work Management forms are perfect for the RFP process, and everything submitted can be easily published to a Confluence page for the next step in the process
Have you made it this far only to realize this won’t work for you because you are on Jira Server or Data Center? We’ve got you covered: our on premise version of Elements Copy & Sync allows you to create Confluence pages.
Start creating pages from Jira
Sound like something your team would like? Get started with a free trial, then let us know what you think.
What do you do when it’s been 15 months since your entire team has been in the office, and you also want to improve your web application security skills? A hackathon!
With Covid restrictions lifting and the vaccination rate increasing, the Elements engineering team organized an in person, in office hackathon focused on security vulnerabilities, with a little help from the local pizzeria 😉
Preparing the hackathon
Security is a big priority for our teams, and Elements’ participation in Atlassian Bug Bounty means engineers are regularly working to improve our apps’ security. But why wait for bugs to be found when you can develop your skills as a team? Software developer Houssem Aloulou had previously participated in and helped organize Hackfests during his studies in Tunisia, and had lots of ideas about how Elements could hold its own hackathon. Focused on web application security, Houssem prepared the event using the Catch the flag (CTF) format.
“I chose the Catch the Flag format because it’s culture is really rich, with a focus on the experience, where collaborating and sharing knowledge between team members is the main focus.”
Ready, set, code!
On Monday June 21, 19 Elements engineers were randomly split into 5 different teams to work on the 9 challenges. Equipped with fun t-shirts and snacks, engineers worked from 10 am to 4pm.
Each challenge earned teams a number of points based on the difficulty, and with half an hour to go before the end of the day, team <script>alert(*La Bamboche*)</script> finished all 9 challenges, with team ILOVEYOU in a strong second place just 2 minutes later.
Houssem explains how he set up the challenges: “I took examples from real security problems we have faced, and wanted participants to think about the impact of those kinds of bugs. The challenges used several servers with several vulnerabilities, and the team that exploited the vulnerability found the flag.”
Each challenge earned teams different points, based on the difficulty, but using hints reduced the earn-able points. Some people tried to get Houssem to reveal a few secrets, but his lips were sealed! An hour before the end of the event, the team scores were hidden so teams didn’t know how close the competition was.
Looking back, and to the future
What did participants have to say about the event?
“A playful way to increase awareness around the different types of attacks and also to work as a team.”
“Inter-squad teams, working together, the escape game feeling: overall a great way to commit to memory the most important topics related to security.”
Based on the feedback, we hope to repeat the event in the future, potentially with more diverse challenges including server breach, man in the middle or other topics.
Sound like an event you’d like to participate in? We’re hiring!
If you’ve been a Jira admin for long enough, you know that choosing a new app to complement Jira’s functionalities is no simple matter. Between gathering the requirements from the relevant stakeholders, assessing the various solutions available on the Atlassian Marketplace, testing the top contenders on your staging instance, getting budget approval, finally setting it up and on-boarding users, it’s sometimes a long journey!
If you’re searching for a solution to leverage your external data in Jira, and want to get it right, look no further.
This article will walk you through the key criteria to take into account when picking an app that populates Jira fields with data from your external sources. We’ve asked several experienced Jira admins and Atlassian consultants for their top tips to select apps to autofill Jira fields with external data that are beneficial to their company for the long run and boiled it down to the following list of questions to reflect on.
5 aspects you must check before choosing your connector
 |  |  |  |  |
#1 Matching your needs to features
“Does the app allow me to cover my current set of requirements? Will it allow us to go further tomorrow? “
Before you get stuck into the rabbit hole of flashy features and beautiful demos, you need to be really clear on your integration needs. For any project to be successful, you need to gather and prioritize pain points to solve, project objectives and requirements. Otherwise, you’ll have a hard time determining what makes a good solution to your company’s challenges.
Let’s review the criteria to take into account when looking at apps to connect to your external data sources.
External data sources available
“Where is the data that you want to bring into Jira stored? “
The first and foremost criteria to take into account is the data sources you need to connect to. Are you looking to retrieve data about clients from Salesforce? or to get employee details from LDAP? Or to fetch asset data from your external CMDB?
[vc_row][vc_column][vc_column_text css=”.vc_custom_1622193388776{border-top-width: 2px !important;border-right-width: 2px !important;border-bottom-width: 2px !important;border-left-width: 2px !important;padding-top: 20px !important;padding-right: 40px !important;padding-bottom: 20px !important;padding-left: 40px !important;background-color: #f5f5f5 !important;border-left-color: #f5f5f5 !important;border-right-color: #f5f5f5 !important;border-top-color: #f5f5f5 !important;border-bottom-color: #f5f5f5 !important;}”]
Specialized VS Generalist Tool
Some apps are specialized in connecting Jira to just one datasource type, such SQL databases, or Salesforce. They will usually pop up first in your search. However bear in mind that that if some day you find yourself with the need to connect to another tool in your information system, you’ll need to call another app to the rescue.
Generalist apps that allow you to connect to several datasource types and set up as many custom fields as you want are a better option if you currently have the need to bring data into Jira from multiple sources, or if you anticipate additional external data requirements in the upcoming years. You can thus factor needs in one app, saving you extra costs and app maintenance.
Be sure to check you can actually access the needed datasources, and that your company’s policy allows you to set up integrations between your data repository and Jira. It would be a pity to do a complete study only to find out that you can’t set up the integration.
[/vc_column_text][/vc_column][/vc_row]
Use of the external data in Jira custom fields
“How will users interact with the data in Jira?”
Depending on your use-cases, you might just need to display information as read-only for users to make informed decisions based on these insights. Alternatively, you may want to create dynamic drop down lists fetching option values from an external data source, to guide users in their selection without the hassle of maintaining the list options manually in Jira yourself.
How you wish to customize the display of the fetched data is also a criteria to take into account when analysing a potential candidate. For instance, each app has different editor options, and some offer more possibilities than others. Keep Jira custom fields best practices in mind. It’s important to take readability and actionability into account when adding connected custom fields to Jira issues, as your end goal is not to clutter the screen or make forms less engaging but rather to empower users to work faster.
Last, consider whether the app offers Jira post functions or integrates with automation apps if you need the values of your custom fields to be set automatically as part of your process.
Reporting possibilities
“How would the data be used in reports?”
The data you’ll bring inside Jira using an app can be extremely valuable to provide more granular reporting to stakeholders. If your initial requirements gathering has surfaced some reporting needs, you’ll want to pay attention to how the raw data in your source can be transformed and formatted via the app to enable teams to use it for reporting on the metrics that matter to them.
What about bi-directional sync?
“Do we need to sync data from Jira with a third-party tool? “
A few specialised apps offer some bi-directional data syncing with other Cloud-based tools. We recommend to have a close look at the depth of the integration and what information can be synced, and how, before committing to a solution.
#2 Assessing the ease of initial set-up
“How much effort will the app configuration take? Do you have the required skills to do it on the team?”
Setting up your connector to match your needs is going to require some effort on your side. Make sure to check the admin interface, overall on-boarding experience and available resources (getting started guides, tutorials, examples…) during your evaluation process.
Pay attention to the skills needed to set up the app. Generally connectors fall into two different buckets:[/vc_column_text]
[vc_column_text css=”.vc_custom_1622193502738{border-top-width: 2px !important;border-right-width: 2px !important;border-bottom-width: 2px !important;border-left-width: 2px !important;padding-top: 20px !important;padding-right: 40px !important;padding-bottom: 20px !important;padding-left: 40px !important;background-color: #f5f5f5 !important;border-left-color: #f5f5f5 !important;border-right-color: #f5f5f5 !important;border-top-color: #f5f5f5 !important;border-bottom-color: #f5f5f5 !important;}”]
Home-Made Scripting VS Low-Code Connector
On the one side, you have home-made scripting apps. These apps can cater to a broad spectrum of needs, on top of connected fields, but require some advanced scripting skills. And the maintenance of your connected custom fields – especially after a few months, or if the person who did the implementation was a contractor or no longer works with your company – can be quite complex, and is often overlooked. Moreover, they have some limitations when it comes to connected custom fields.
On the other side, low-code connectors focus on one thing: enabling you to create connected Jira custom fields, and they do it very well. You’re guided all along the way from data source connection to custom fields creation and configuration. They require much less technical expertise and are a lot easier to maintain, while offering a lot of possibilities to configure your custom fields according to your specific needs.
For more information about the difference between these type of app, read our comparison of the two category leaders.
[/vc_column_text]
#3 Taking maintainability into account
“What if something in our configuration needs to change? How easy will it be to do it?”
As the saying goes, “change is the only constant”. There will always be new needs to cater to, changes in processes, new teams on-boarding in Jira. Maintainability isn’t an aspect to overlook, as once you choose a solution, you’ll be responsible for updating your custom field configurations every time they need to be.
It’s not only about how much time will it take you to update your app configuration if something changes in your processes. You’ll want to ensure the vendor’s capability to support you in the long run by checking the release frequency, whether the app is supported or not and if their website looks professional.
#4 Evaluating support & documentation quality
“How will the vendor help you get up to speed with his app?”
An app vendor that supports you can make all the difference. Before committing to an app, it’s always best to ask the support team a question and see how long it takes them to respond. Also, make sure to check out their app documentation to see if they have tutorials, examples or step by step guides to help you get started.
#5 Looking at the costs the right way
“How much will the app really cost us, including not only the license fees, but also the time spent on the implementation and maintenance of the solution?”
Don’t just get attracted to a lower price tag on the licensing: take into account the total cost of ownership of the solution, including the time you’ll need to spend setting it up and maintaining it. Do the same for each contender, and weigh that against the cost of continuing to work the same way, without bringing your external data inside Jira.
The solution with the best long term ROI isn’t always the one you think. It’s easy to be fooled by a “cheap” option that’s going to take you ages to set up properly. If you look at costs the right way, you should spare yourself troubles down the line.
The bottom line
Choosing an app is hard, but by being thorough in your analysis and reflecting on the right questions, you can be confident that the decision you’ll make will have a positive impact on employees’ productivity, while not generating too much overhead for you, now or later.
It’s all about being willing to take it one step at a time and ask good questions.
Cloning and moving is the most time efficient solution to make existing information useful for other people or additional situations within Jira. A classic example is issue escalation, where you need to clone an issue from your support portal to a software team. Or maybe you have issues created regularly by internal employees, and you want to be able to clone an issue to another project based on a custom field.
What are the options for automating a process to clone and move Jira issues based on a custom field? We’ll take a look how you can clone and move Jira issues based on a custom field with native Jira options, as well as with an app. We’ll also see how automating copies as part of a workflow transition with Elements Copy & Sync can help your team.
Jira out of the box clone and move options
Issues can be cloned and moved individually with native Jira features available from the action menu. The manual process is fully detailed in our Ultimate guide to clone and move Jira issues.
How frequently do you need to clone and move issues? If it’s just a couple times a month, this could be the best option. Jira users would just need to check the details in the issue, and move the clone manually. Note you can’t see the issue details after you click on Move, so if you need to select a project based on those details, make a mental note beforehand.
How to clone issue to a different project based on a custom field
Looking to make the process automatic? Or reduce the risk of errors? You can streamline the process (and prevent moving issues to wrong projects) by using an Elements Copy & Sync operation (Server or Data Center) or recipe (Cloud). It works by
- setting a project picker custom field,
- launching the Copy & Sync operation/recipe, and
- creating a linked clone in the right project.
Let’s look at how you can set this up on Jira Server or Data Center. If you are on Jira Cloud, follow this Elements Copy & Sync Cloud tutorial.
Step 1: Create a project picker custom field
From your Jira admin, create a new custom field, selecting “Project Picker” from among the Advanced field types. Give it a clear and understandable name that is unique to your Jira instance, and save.
Step 2: Add project picker custom field to issue screens
Don’t forget to associate your custom field to all the various screens where you’ll need it, like the view/edit screen. New custom fields are added to the end of the tab on the create issue screen, so you may need to adjust the order of your fields.
Step 3: Configure Copy & Sync operation
If this is your first time configuring Elements Copy & Sync, you will need to create a field mapping before creating your operation.
Once you have a field mapping, you can create a copy operation. When configuring the operation, instead of selecting one project or a category of projects, select “From Custom Field”, and then chose the project picker custom field that is displayed.
Step 4: Clone and move issue based on your custom field
From your issue, make sure your project picker field has a value, then click on the Elements Copy & Sync operation button to create the clone in the right project. In this example, the operation also adds a link between the clone and original issue.
Trigger clones as part of a workflow and create on transition
Copy & Sync operations can be added as post functions to workflow transitions to make the process even smoother. Elements Copy & Sync will automatically clone issues to the right project when you transition issues.
To add an Elements Copy & Sync operation to a transition, you will need to edit your workflow and add a post-function.
Once you’ve published your new workflow, you probably want to add the project picker custom field to the transition screen that will trigger the operation so that it’s easy for agents to update the field. This is what that process could look like:
This example also includes an Elements Copy & Sync Data Panel on the incident issue, which helps you customize the information you display from linked issues (for comparison, the cloned issue in the software project has the native linked issue panel).
Using the operation as part of a workflow transition was smooth and easy: support agents can follow their usual process and transition issues, then go back to their queues. All the important information from the source issue has been cloned in to the right project for the software developers.
Automated cloning and moving is a recipe for success
The combination of native Jira project picker custom fields with the app Elements Copy & Sync is a recipe for success for cloning and moving issues to different projects (you could even say it makes it a piece of cake 😉 ). All Jira users can confidently clone and move issues based on a custom field, without worrying about remembering which project to chose. Adding the clone and move operation to a workflow transition means reducing the risk of errors as well. You can even compare the number of clicks required to manually clone and move an issue versus using Elements Copy & Sync!
Curious how a real company implemented Elements Copy & Sync to escalate issues from a support portal?
Teams all have their specific needs when it comes to capturing data in Jira custom fields. As a Jira admin, it is your job to ensure issue creation screens do not turn into endless forms nobody wants to fill in, while still collecting the information that matters. Select lists, which reduce the complexity of providing data by guiding the users with a limited number of predefined options they can choose from, can seem like a miracle solution to many of your custom fields needs.
But, they’re not a panacea and going beyond native Jira custom fields is sometimes necessary, notably if you want to create dynamic drop down lists.
In this article, we’ll review:
Custom select lists in Jira: the pros and cons of the native options
When you need to limit users to chose from a list of options in a custom field, you have several possibilities in Jira. We’ll discuss each one of them, their pros and cons, and the situations in which they best apply.
Radio button
Radio buttons allow users to select one option from a list. Custom radio buttons created by a Jira admin look like this:
Radio buttons, just like checkboxes offer the advantage to display the full list of options vertically, so all options are instantly visible to the user. They work perfectly for “Yes / No” questions, or any other use-case where you have a limited number of mutually exclusive choices.
However, if the list of options users can select from is longer than three, you should consider alternatives to a radio button, as otherwise it would clutter your issues screens.
Checkbox
Checkboxes are the counterparts of radio buttons, they’re perfect when you want users to be able to select multiple values from a small list of options (ideally three at most, but it is commonly accepted to go up to five).
They offer the advantage of making all the options visible at a glance, thus making it easy for users to quickly compare and pick options.
Single choice custom select list
Single choice custom select lists are drop down lists that allow users to select one single option to complete the field.
A common use-cases for single choice select list is to create two select lists for managing risks associated to the ticket (one for impact, one for probability).
While they’re more compact than radio buttons, they tend to have a higher drop out risk as they take longer to browse and edit: it takes two clicks to select an option with a drop down list, while it takes only one with a radio button. One could be tempted to mark such field as required, but we recommend not to abuse the required attribute.
Another known limitation of the native custom select lists is that they do not offer any autocomplete feature (while system fields such as Fix Version do). This tends to make it hard for users to browse lists with many options.
Custom select list with multiple choice
Custom select lists with multiple choice allow to select multiple options from a list.
Their UX isn’t really user-friendly: one needs to scroll in the select list zone to see past the fifth option available, and to use Ctrl + Click (or Command + Click for mac users) to select multiple options. Moreover, there’s no autocomplete so it’s really hard to browse options if you have many to select from. That’s why we don’t recommend using them too much.
Cascading select list
Cascading select lists allow users to narrow down their options by branching a parent list with a child list. Users first need to make a selection in the parent list, and then the child list will display the set of options corresponding to the parent value selected. They’re limited to two levels only (so no grand-children! ) and displayed side by side.
If you have a large number of values that you can group into different categories, then cascading select lists will help users make their selection and spend less time browsing the options.
At the moment a Cascading Select Custom Field that is marked as required, will pass if only one field is selected.
A general limitation of native custom select list
There are a number of best practices when it comes to managing Jira custom fields wisely. One is to avoid creating option fields that have to be manually updated frequently, as the burden of updating the list of options can only be carried by a Jira admin. Not only is it a pesky task that puts you in a position where you’re the bottleneck, but it can also lead to users selecting outdated options, leading to inaccurate data in the system.
A smart way to bypass this limitation is to use an app such as Elements Connect, providing you have a place where the list values are maintained up to date (they can also be stored in Jira using a dedicated project). We’ll look at this possibility in the following sections of this article.
Doing more with apps: dynamic drop down lists with Elements Connect
As presented in the previous section of this article, there are a number of limitations to the native select lists options provided by Jira. Using an app such as Elements Connect can help you enhance your Jira custom select lists and cover a broader range of use-cases. Elements Connect is an app for Jira that allows you to fetch data from your external datasources (CRM, CMDB, LDAP, homemade database…) and display it in Jira custom fields.
Here’s where Elements Connect can help leveling up your Jira custom fields game.
- Say goodbye to the manual maintenance of select lists options
Fetching your list values from an external source of truth allows you to ensure data consistency, without the recurring hassle of manually updating the list options in Jira. Data is pulled in real time directly from your external datasource.
- Use autocomplete in your dynamic drop down lists
Let users search the list of options with an autocomplete. This is particularly useful in case you have a long list of values to choose from.
- Present your select list options beautifully
If needed, you can customize the way your data is displayed using html to make it easier for users to browse options.
- Create cascading drop down lists on more than two levels
Create an infinite number of levels to cater to your most complex needs.
Unlike native Jira fields, you can change how the custom field is displayed and how users interact with it after it has been created.
No external data source containing the list options? Consider this hack
If you don’t have an external datasource where you store and update lists values (or can’t access it because of network restriction at your company) but still want to benefit from dynamic select lists, you can use Elements Connect to fetch data from Jira, by setting up your list of options in a dedicated project as Jira issues’s fields as show below.
It’s much simpler to set up and maintain than creating custom scripts, and you can order list options.
You can then grant a group of power users access to the project. This way, they can update the list of options by adding and removing the issues available in the project, without needing your help.
Choosing the type of Jira custom field best suited to your use-case
To determine the type of custom field that’s best for your “select list” use-case, you can follow the systemic approach proposed in the below decision tree.
First, you need to look at how you want to manage the options of your list, then decide how the information will be presented to the users.
User experience is key to adoption
There is no such thing as a one-size fits all solution. The guiding principle when it comes to custom fields in Jira is to reflect on the various needs you’re trying to reconcile: the need of the people who create the tickets, the needs of the ones who work on them, the need of those who need to aggregate data about them.
Simplifying these users’ experiences is key to the overall adoption of the solution. Sometimes it means saying no to a custom field request (for good reasons), sometimes it means going for the extra mile and setting up an integration between your external data sources and Jira so users can retrieve the information they need without the need to switch context or scroll down through a massive list of options.
At the end of the day, it is your call.
There are lots of reasons you might need to clone and move a Jira issue: escalating a ticket from a service desk project to a software project, replicating a task from one Jira project to another, or maybe making issue details available to someone who doesn’t have permissions on the original project.
While cloning an issue and moving it are available out of the box in Jira, there are other solutions to consider. By understanding the different options to clone and move, you can get the most out of Jira and optimize your processes.
Let’s look at the ins and outs of cloning in Jira.
What we’ll cover in this guide to cloning and moving
- When to clone an issue to another project
- Jira clone vs duplicate
- How to clone and move issues in Jira
- Permissions: how to control cloning and moving in your Jira instance
- Use case: cloning and moving from Jira Service Management to Jira Software
- Pro tips checklist for managing how users clone and move issues in Jira
When to clone an issue to another project
Cloning and moving is the most time efficient solution to make existing information useful for other people or additional situations within Jira. There are lots of use cases where it might make sense to clone an issue to another project:
- move issues from the Designer’s board to the Developer’s project
- share a bug or change request from a support portal with an engineering team
- need to clone between Company managed and Team managed projects
- move/clone issues from instance A to B, and vice versa
- replicate an epic issue for multiple teams that each have a project
- clone a task from current project to add it to an epic in another project
After all, you already have lot of information from a customer or an employee, and you probably spent time configuring all those fields. Make sure that information is used again and help your entire team leverage the power of Jira!
Jira clone vs duplicate
Jira has its own jargon, so just to be clear, when linking two issues on JIRA, what is the difference between one issue “cloning” another, and an issue “duplicating” another?
The words are synonyms in many situations, but when we’re talking Jira, a clone is an issue that was created by copying another issue, and a duplicate is an issue that repeats another issue. For example, a duplicate happens often when two clients raise the same bug: often the second/third/nth person doesn’t know that it’s already been reported.
There are a number of links you can add between issues, and clone and duplicate are two on the list that may seem to be identical, but actually serve a different purpose.
How to clone and move issues in Jira
The methods to clone and move issues basically fall under two main categories: native Jira functionalities, or add-ons.
In the add-ons category, you can choose from solutions like Automation (which now is included free with Jira Cloud), or other apps available on the Atlassian Marketplace.
Let’s take a look at the pros and cons of various solutions to get a better idea of the situations for which they are the most suited.
Option 1: Native Jira options to clone and move issues
Every Jira instance offers out of the box the clone feature and the possibility to move issues. Both clone and move are available from the Actions menu.
To clone an issue, just select clone from the Actions menu. Jira automatically adds “CLONE” to the beginning of the summary of the new issue, and you can activate the option to clone attachments if you want. No other options are available.
You can then move this issue to another project. First you need to select the destination project and the issue type. The drop down field to select the project shows you first the projects you selected recently, and then below all of the projects you have access to in the instance. After confirming the target project and issue type, you have to map the statuses, and then update any fields. If your new issue has any custom or required fields (like a story points estimate for a Story issue), you may need to complete that before you can finish moving the issue.
Once you’ve moved your issue on Jira Cloud, you will still have the clone link to the original issue, so if you don’t want that you can remove it. If you are using Jira on premise, you won’t have this clone link.
When moving an issue that has custom fields to another project, you need to make sure the custom fields exist on the target project. Even if the custom fields do exist, you may still be prompted to set values for them in order to finish moving the issue. If you are using Jira Cloud and trying to clone and move between Team managed and Company managed projects, be aware that you may not be able to clone everything from the issue since Team managed projects are self-contained and do not share custom fields with other projects.
Want to better manage your custom fields in Jira? Check out our guide to custom fields.
Pros and cons to native Jira options to clone and move issues
Built in cloning in Jira lets you clone most things from the issue, including attachments, and it’s relatively simple to use.
Moving issues with the native Jira function is pretty straightforward too. There’s nothing to configure ahead of time, you make all the choices each time you want to clone and move an issue.
But this process can be really cumbersome if you
- need to do this regularly,
- need several team members to do this,
- have dozens or hundreds of projects on your instance,
- want changes on the original issue to be synchronized to the clone
- or need to clone time tracking, comments, or links to Confluence pages.
Or maybe you just want custom fields to be cloned without having to set values each time. Let’s not even count the number of clicks you need to do to clone and move one issue with 2 custom fields and then remove the clone link!
When to go with native Jira functionalities
For a small instance with a small team, cloning and moving with the native Jira options is a solution without any added cost or configuration, but the risk of error and time spent on the process only increases when you have lots of projects or a larger team cloning and moving. This solution works to clone attachments, some custom fields, but not comments.
Option 2: Automation options to clone and move issues
Automation is now included in Jira Cloud instances, as well as being a paid app for on premise instances, and you might already be using it for other use cases (like automatically closing a Service Management issue if the customer doesn’t reply for a certain number of days).
Automation can be configured to clone an issue, or to create a new issue in a different project and copy values between the two issues.
You can get started using Automation for Jira Cloud by getting some automations from the template library.
The template library includes an example automation
When issue is transitioned → clone issue to another project and link the two issues
If you are using Jira on premise (Server or Data Center), the documentation on how to clone an issue with Automation is available here. The clone made with Automation for Jira will not copy attachments, issue links, or comments, but you could configure additional rules to sync comments, for example.
Pros and cons to Automation for Jira to clone and move issues
Automation for Jira is now included in Jira Cloud instances, and you might already be using it for other use cases. It’s a powerful app with a large community.
But “now included in Jira Cloud” comes with some important caveats:
- While an automation to clone issues within just one project can have unlimited executions, an automation rule that is applied to more than one project, it’s considered a global rule and will be limited.
There are some additional caveats that rules to create issues are not counted even if the issue is created in a different project.
Setting up an automation rule is also not the most intuitive task. Choosing which fields you want to clone has to be done field by field. And specifying additional field values to be set using a JSON objector is another way of saying “we hope you are ready to spend lots of time on the documentation”.
You can trigger rules manually or automatically so either users decide when to execute the automation or it’s executed automatically, but Automation is at its most powerful when everything is triggered automatically.
When to go with Automation for Jira app
If specifying valid JSON objects for advanced field cloning is a piece of cake and your team has structured and complex processes for using Jira, Automation could be the right solution for you. You will have more control over cloning custom fields compared to the native options, but you will need to spend considerable time configuring and maintaining your rules. You will also lose the possibility to clone attachments.
Option 3: Clone and move plugin Elements Copy & Sync
A number of apps allow more flexibility to clone and move issues to better meet your needs, and Elements Copy & Sync offers a balance of robust features with user friendly configuration.
In order to clone and move an issue, you will need to first configure a recipe, which lets you specify conditions for the issues to be copied (projects, issue types, priority, etc), conditions for where the clone will be created (project and issue type). This can be a set project or issue type, or a selection the user can chose from. To complete the recipe, you need to specify what will be cloned: fields, attachments, and comments. You can chose to clone all available fields, or only some, for instance excluding certain custom fields. The field mapping options are really easy to use to copy information to different fields, for example copying the Description or Root cause of the source issue to the Environment field on the new issue.
Once you have activated your recipe, you can select it from the Copy & Sync window available through the Actions menu. You can also add the recipe as a post-function so it clones an issue to another project as part of a workflow transition.
Pros and cons to clone and move plugin Elements Copy & Sync
Using an app like Elements Copy & Sync allows you to configure
- very specific clone and move recipes,
- specifying which fields to copy (and where),
- whether or not you want attachments and comments copied, and
- if set as a post-function it executes in the background for no extra clicks for your user.
Users are guided in what they clone and move, with a streamlined process, so the risk of error is drastically reduced compared to the native functionalities. Configuring recipes is much easier than configuring automation rules, especially if you want to modify which custom fields you clone. If you are using Jira on premise, Elements Copy & Sync lets you create remote issues as well. You can copy attachments and comments with the app.
As an add on, there is an added cost to take into consideration.
When to go with Elements Copy & Sync app
If you want to streamline your clone and move processes to reduce errors and want app configuration and maintenance to require a minimum amount of time, Elements Copy & Sync could be the right solution for you.
Permissions: how to control cloning and moving in your Jira instance
With a handful of users, controlling who can clone and move issues on your instance might not seem like an essential need. But as the adoption of Jira spreads throughout your company, the risk of mistakes increases too. What if from the original 10 projects, you now have 60? Cloning the wrong issue or moving a clone to the wrong project is an easy mistake to make, which then requires additional clean up work and regular vigilance.
Setting permissions with native Jira clone and move options
For setting cloning permissions, you can remove cloning options for all users on Jira on premise, but you can’t deactivate cloning for only a subset of users with the OOTB functionalities. You can set move issues permissions based on roles, but users need to have create issue permissions in the project where they are moving the issue.
Setting permissions with Automation
Conditions can be set on rules to check whether a user exists or is in a specified group before executing an automation, which can let you limit issue cloning to a subset of users.
Setting permissions with Elements Copy & Sync
Elements Copy & Sync Cloud lets you restrict which issues can be cloned based on issues details (like the type, priority, or a specific JQL filter) and restrict where it can be cloned. If you only want certain issue types or issues of a certain priority or in a certain status to be able to be cloned as part of an escalation process, you simply need to set up the recipe with that criteria, and users will only be able to use the recipe when the issue meets all the criteria.
You can also set permissions based on roles. You can define specific permissions on the user, group or role (on premise only) of the person who is triggering the clone.
See how this works on the Activation tab with the on premise version, or the Triggers tab in cloud version.
Use case: cloning and moving from Jira Service Management to Jira Software
Here’s a pretty common use case for teams looking to clone and move an issue: a customer raises a request on a Jira Service Management portal, and it requires the work of the software team. The details of the bug the customer reported need to be cloned and moved into the software developer’s project where they can add it to their next sprint.
Using Elements Copy & Sync for issue escalation
This is how Elements Copy & Sync can be used to clone and move issues easily for issue escalation.
Here is the summary of the recipe that has been set up.
As you can see on the Source and target section, the recipe is available for all issue types on the Tellurian Support Desk that are In Progress, and creates the clone in one of three pre-selected projects, as a bug, and with the link ‘blocks’.
In the Created content section, there’s a quick view of whether fields, comments, and attachments from the source issue will be copied, and synchronization has also been activated (any changes in the original ticket on the support desk like a field change or new attachment will be synchronized to the clone).
This is what it looks like for an agent using the recipe from Jira Service Management:
Beyond strictly cloning and moving the issue from the service desk to the software project, there are also a couple things that would be handy in this situation that are available with Elements Copy & Sync:
Having the status of the cloned issue visible on the customer portal so they can stay informed of the progress. Your users will need to have permissions on the linked issues.
Having fields, comments and attachments synchronized from the JSM issue to the Software issue so the developers get any new information the customer might add to the issue after the initial clone was done. You can choose which way information is synchronized.
Pro tips checklist for managing how users clone and move issues in Jira
- Make sure Jira users are correctly assigned to roles or groups, especially if you are going to limit move issue permissions based on those roles
- Look at the custom fields in the different projects to make sure the cloned issue in a new project remains coherent
- Check your source et destination workflows
- Ask your project admins or heavy Jira users how they want users to be able to clone and move issues: individually? choosing the target project themselves? invisibly in the background as a post-function? in bulk?
- Try any clone and move app in a staging instance first
By picking the best option for your needs to clone and move Jira issues, you can make sure you’ve optimized your instance for your users and simplified your job taking care of the instance.
Read our article on how to clone and move issues based on a custom field