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
Jira comes equipped with many useful standard fields, designed to capture essential business data. However, it also lets you add custom fields in addition to the built-in fields to fit your business’s specific needs.
While this allows for a great deal of flexibility, it is essential to carefully manage your custom fields: it’ll make your administration easier as having too many custom fields may affect Jira’s performance but also your work as a Jira admin.
Below, you’ll find essential resources, how-tos, and expert advice to help you adjust the way you manage custom fields in Jira so you capture the right data for your business, while ensuring your configuration is sustainable in the long run.
Keep on reading to understand Jira custom fields, or jump ahead to the section that interests you most.
- Essentials things to know about custom fields in Jira
- Do’s and Don’ts for managing custom fields in Jira
- Optimizing Jira custom fields: a step by step process
- Governance: best practices to handle Jira custom fields requests
Essentials things to know about custom fields in Jira
What are Jira custom fields and how do they work?
Custom fields complement the built-in fields in Jira by allowing you to track information specific to your team’s needs inside Jira issues. You can create custom fields to capture virtually anything and choose to display any number of custom fields when creating, editing, viewing or transitioning Jira issues.
They also act as filters for Jira issues, when performing issue search, in reports or dashboard gadgets, so users can know better where their work stand at a glance.
The anatomy of a Jira custom field
When talking about custom fields, there’s more than meets the eye. Jira custom fields each have a number of attributes that will define what data they can contain, and how this data will be presented, and searched for instance. Here’s the list of attributes1 you’ll be manipulating when creating, editing or deleting custom fields.
- Name: the label that appears to the left of the custom field when it is displayed to a user on a screen.
- Description: the help text that appears next to the custom field on hover.
- Default value: the default value of the custom field when it is first prompted to a user.
- Context (also known as custom field configuration scheme): the combination of project(s) and issue type(s) for which a given default value and a set of options will apply.
As we’ll discuss later in this guide, you can and often should create multiple contexts for a given custom field, allowing you to associate different default values and options with particular projects or issue types. This can help limit the number of custom fields by reusing them in a different way across your Jira instance. - Screens: the screens on which the custom field will appear when an issue is created, edited or when it is transitioned through its workflow. A screen also allows you to split subsets of fields across multiple tabs.
- Search template: the mechanism for making a custom field searchable via Basic Search and Advanced Search, also responsible for the indexing of custom fields.
- Options: the values from which users can choose . These values can be manually entered by a Jira admin or live fetched from an external datasource using an app.
Options are only available for select lists, multi select lists, radio buttons, multi checkboxes and cascading select lists. - User filtering: the set of users which the end-user can pick from in a User Picker Field. These options can be limited to users in specific groups and/or project roles.
Additionally, when defining field behavior for certain project(s) and issue type(s) combinations using field configurations, you’ll be able to configure:
- Hide/Show: whether the field is visible on the view or hidden
- Required/Optional: whether the field must be filled or is optional
- Renderers: renderers defines how a field’s value is going to be displayed, they affect the view, not the data itself.
Jira custom fields and reporting
Custom fields are a great way to add rich data to your issues, and they’re extremely useful data points to get insights from in reports, search queries or on dashboards.
However, not every custom field type is built equal when it comes to reporting. Structured custom fields such as select and multi select lists are particularly effective, as the user has a limited number of options to choose from, and thus there’s a known fixed set of options to search from and display in your reports. On the other hand, text fields are less structured and can only be searched using the contain (~) operator, meaning they’re a lot less useful in reporting as people don’t always enter data correctly or as expected by the JQL query used in the report.
Cloud only: custom fields in Next-gen projects
If you’re using Jira on Cloud, you have the option to empower your users to create Next-gen projects. Next-gen project allow users to create and set-up their own issue types and custom fields, basically to configure their project to match their team’s specific needs without relying on a global Jira admin. These projects are self-contained, meaning fields created in next-gen projects can’t be used by other projects which should prevent them to affect performance globally. Similarly you can’t use a custom field created in a classic project on your next-gen project issues.
While this “DIY” approach offers some benefits in terms of flexibility, you should think twice about going down that road, especially if you need cross-project reporting that requires shared custom fields. Before teams create Next-gen projects, make sure they can clearly define the business value of having a self contained project with custom fields that can’t be shared with other projects as there is no easy turning back.
If you wish to explore this new paradigm to project management in Jira, consider starting with a small number of power users that you will train (by default, anyone can create a next-gen project, so make sure you set up the appropriate permissions). You can share this best practice guide about custom fields with them as a reference.
Apps and custom fields
Apps are additional bricks Jira admins can add to their instance, allowing them to customize the tool to their company’s specific needs and enhance it with further functionality. There are two ways apps can leverage custom fields: first to store additional data related to the app functionality in Jira, and second to reuse the data stored in the fields that are already available on the instance as an input. How custom fields are used depends on the app functionalities. For instance an app such as Tempo Planner will leverage data stored in fields to display a plan while an app such as Elements Connect will provide custom fields that fetch their values from external data sources.
While the custom fields types provided by Jira are already extensive, you might want to consider using an app to enhance its capabilities when in need of calculated fields (as Jira can’t natively provide with any kind of computation in custom fields) or when the information the field will capture already exist in one of your external referential and you’d rather fetch it from there.
One important thing to note is that when an app is deactivated or uninstalled, their custom fields remain in the Jira database even if they are removed from screens and the custom fields section of the Jira admin.
Do’s and Don’ts for managing custom fields in Jira
What are the considerations for creating custom fields in Jira? Here’s our curated list of do’s and don’ts for effectively managing your Jira custom fields, and avoiding custom fields bloat.
DO’s
- Be careful how many custom fields you define in Jira
Every custom field has a cost in terms of performance for the instance, but also in terms of time of complexity to fill in requests for users. Strive to challenge the necessity of each custom field early on, this will save you from having to run a custom fields audit because of poor performance later on. - Make custom fields names generic
Try to give custom fields non-specific names that allow you to reuse them in other places. Use context to define project / issue type specific options, if needed. For example, name your field “Rating” instead of “Support Rating” . - Translate custom fields names
If you have users using different language packs, make sure you translate your custom fields accordingly. This will ensure your custom fields are understood correctly. - Use custom fields contexts judiciously
Restrict the custom fields context where appropriate, and avoid using global context when it’s not necessary. This will help optimize your Jira instance performance. - Automatically fill in Jira fields when possible
As a Jira admin, your job is to strive for simplifying issue creation for users while maintaining a high-level of data accuracy and enough information in the Jira issue for it to be effectively handled. If you already have the information you’re requesting from users stored in an other system, consider using an app to retrieve data from external datasources, automatically fill fields or guide users with select lists that fetch their values from your external sources.
DON’Ts
- Don’t duplicate names
Do not create new custom fields that have the same name as other existing fields …or search in JQL will become a nightmare for users. This can also lead to administration mistakes and custom script errors. Always run a check to see no other field in the instance share the name of the field you’re about to create. - Don’t create option fields that have to be manually updated frequently
Avoid creating option fields if the options provided are likely to frequently become outdated and require a manual update as data is likely to become inaccurate. However, if the list of options you want to provide is being maintained in an other system (your CRM, an Asset Manager…), an app that can fetch this data and display it in Jira can spare you the maintenance of the list options in Jira and provide an efficient solution. - Don’t abuse the required attribute
While there’s a strong temptation to make fields required, you should use this option sparingly as it makes creating tickets more difficult. If a custom field must be required, always have a way for the user to say “I don’t know”, otherwise you might end up with erroneous data.
Optimizing Jira custom fields: a step by step process
When too many custom fields affect your Jira instance performance
Research has shown that having too many custom fields can have a dramatic impact on your Jira instance performance, as the response time of any action that involves custom fields is affected by the raw number of these objects available in Jira.
As show below, the difference in response time per action for an instance with 1400 custom fields and one with 2800 is affected the most for Search with JQL, and Create issue, two commonly performed actions.
If you’re experiencing slow load time on your Jira instance, optimizing custom fields can lead to significant improvement in the quality of service you deliver to your users. Here’s a high-level step-by-step process on how to approach this project.
1. Audit your Jira custom fields
First, you need to get a clear list of the fields that are currently implemented in your instance. There are a few way to identify them: you can do a manual examination, use an app from the Marketplace such as Cleaner for Jira or Custom Fields Usage for Jira (Server only) or Jira’s built-in Custom Fields Optimizer (Data Center only).
Once you’ve established the list of custom fields available in your instance, it’s time to classify them and assess whether they’re still needed or not.
Process step by step in your investigation: identify how they were created (by Jira, by an app, or by an admin). For the ones that were created by an admin, check for duplicates or fields that have too narrow names, determine the fields’ scope and current use in projects, screens, workflows and users’ JQL queries. Also question the business value of the custom fields.
Once you’re done reporting this information in your spreadsheet, you’ll be ready to move on to the next step: deciding on how to optimize your Jira custom fields.
2. Decide what to do with your custom fields
Now that you’ve assembled all the necessary information about your Jira custom fields, it’s time to decide what to do with them. For each custom field, you have six options:
- Keep it as is
- Rename it for the sake of clarity and re-usability
- Delete it purely and simply
⚠️ Bear in mind that this operation can’t be undone, and the values in the database will be deleted. - Hide it from the screens while preserving the data
- Limit its scope to specific projects context
- Merge it with other custom fields that are essentially the same
3. Prepare stakeholders for the changes
Loss aversion is a very common fear. When working on optimizing your custom fields list, always make sure to explain to users and project admins why you’re doing this, and that in doing so you will not take away the functionality from them but rather find a more elegant way to provide them with this functionality.
Make sure also to state that you’ll only delete fields that aren’t used anymore, and with the agreement of the project admins of projects previously using that field. Be prepared to share data that shows how the field isn’t valuable anymore.
4. Advice for the actual implementation
Always ensure that your changes are tested in a test environment before rolling them out to production, and allow enough time to these tests. This may seem like an overkill sometimes, but be careful so that no data that’s critical to a team is lost in the process.
Governance: best practices to handle custom fields request
As the saying goes, an ounce of prevention is worth a pound of cure. Whether you’ve had to go through an audit and field clean up, or are just getting started with custom fields, here are some tips around custom fields requests management that will help you keep your Jira instance clean and performing well.
Pieces of information to collect for each new field request
While you can provide your users with a request form for new fields directly in your Jira support project, you’ll want to spend some time with the project lead or user that brought you this request to interpret their requirements for the new field, understand the underlying business needs and determine how to translate these requirements in your Jira instance and whether a new field is indeed needed or not.
For each new field request, try to get the most context you can. By the end of your investigation, you should know:
- the desired field name
- the purpose of the field
- the type of data that will be collected ( text, number, date, checkbox, select list…)
Pay special attention to interpreting the user’s requirement around the field type correctly, as once a field is created with a certain type it can not be changed later. Asking the requester for examples of the data the field will contain can help prevent such errors. - how and when in the issue lifecycle the data will be collected (manually entered or synced from an external referential)
- the screens on which the field should be shown
- for select lists and checkboxes, the list of options the user can choose from
- the validation rules for the field
A checklist for evaluating requests for new custom fields
Just because you can, doesn’t mean you should. By carefully assessing the requests you get from users you’ll truly be in a position to make the best choices for your Jira instance.
Take a moment to assess whether or not a new custom field is legitimately needed by reflecting on the following aspects:
- What would be the business value of the new field?
Always verify there’s a clear purpose for capturing a piece of information in a new field by asking the requester: how will knowing this information impact how you do your job? How is the data needed to perform your work or for reporting? It may sound obvious, but more often than you think you’ll find out the need isn’t clear. - Does the data need to be structured?
Ask the requester: will you search or filter issues based on this field’s value? will you need to run reports based on the values of this field?
If not, consider simply specifying what’s needed from the end user in the hint of the description field on the issue creation screen. - Will the new field be used by multiple teams across the organization?
Seeking for mutualization of custom fields across your Jira instance is a very effective way to fight custom field proliferation. Some companies even have a requirement that at least two teams benefit from the new field for it to be created. - Is there already a built-in Jira field or an other custom field that could fit this purpose?
Jira comes with a lot of built-in fields, and you probably have already added custom fields to fulfill previous requests on top of that. Before moving further with a new custom field creation consider reusing an existing field with a new context for instance. - How long will it take a user to reliably collect and submit the information?
For fields to be useful, they need to be filled correctly with accurate information. Remember that every field has a cost: no one likes to fill-in endless forms. Where possible consider automatically populating dropdown list options or read-only fields with data from your external databases or Cloud apps. This will save your end-users time while at the same time ensuring the accuracy of the data in Jira.
Once you’ve answered these questions, making the call for whether or not to create a custom field should be a straightforward decision.
Make managing custom fields requests a part of your Jira governance processes
Each company has its own way of governing its processes – yet there are some common best practices that can help you ensure your Jira instance keeps running smoothly and rules about its customization are well understood. Consider having a governance policy around custom fields and make it easy for users managers and executives to find. You’ll want the rules for how new objects such as custom fields, workflows, etc get added to Jira to be clear and unambiguous for everyone.
A Jira Advisory Board made up of different profiles (executive, project lead, end user…) is also a good way to make sure decisions are taken based on the collective insights of different stakeholders and with a global perspective, ultimately leading to more trust and efficiency in the way the solution is administered.
Maintain and Sustain
Ensuring the performance and optimal configuration of your Jira instance is not a one time job. We recommend you regularly audit your custom fields and make sure that you and other Jira administrators at your company are following the quality standards and procedures that you’ve put in place to ensure custom fields are managed the right way at your company.
Make your Jira instance sustainable for future generations to come. There will be a day when you will leave, and you should leave with pride that you have built a maintainable and sustainable environment that has helped your company grow the right way.
References
1. Configuring a custom field, Atlassian Documentation
2. Performance testing for custom fields, using the methodology detailed in their Performance and Scale testing report for Jira Data Center, Atlassian Documentation
At a glance
“Speed and performance in today’s world defines a brand.”
Apcela, an American pioneer in the development of high-performance cloud-optimized enterprise networks, lives by this motto.
This notion of speed and high-performance must be reflected in all their services, including the customer support. Having the right tools to deliver high-quality customer support is therefore crucial.
With the help of Elite IT Consulting Group, an expert in Atlassian solutions, Apcela built an efficient support portal using Jira Service Management (formerly Jira Service Desk) combined with the apps Elements Connect and EazyBI.
The main goal was to provide a fast & easily-monitored incident management of their customers’ services.
Elements Connect helped achieve this goal by connecting Jira to the external CMDB storing network data, and thus centralizing all the information needed in each incident ticket so the support team can solve them faster.
EazyBI was implemented in order to create reports, and the compatibility between Connect and EazyBI meant the JSM solution was key to efficiently monitoring the assets of all clients and deliver a high level of performance in incident management.
The challenge: provide a fast & easily-monitored incident management service
Speed is in the DNA of Apcela. That has to be reflected in the nature of their products— cloud optimized networks— but also by every service around them.
That’s why it is crucial for them to deliver the same speed and quality in their customer support management as their products offer.
They reached out to Elite IT Consulting Group, Atlassian Solution Partner, to help them in this task.
The goal was to implement a high-quality customer support environment to manage incidents on their customers’ assets easily and efficiently.
Apcela had the following requirements:
- Ease the life of support agents & customers when raising an incident. To do so, it was important to provide them with all the information they needed on the assets which were impacted (routers, networks, etc).
- Asset & customer data must be updated live, due to constant changes in assets & services ; new locations or new networks connections are made every minute.
- Easily monitor customer service and build activity reports based on the main criteria for them: the service-level agreements (time to first response & time to resolution). SLAs were especially crucial for them because an incident on one service can impact the work of hundreds of users. The sooner an incident is detected, the better.
The solution: automate data centralization in a high-velocity support portal
Elite consulting team helped find the best solution to match Apcela’s requirements.
To monitor customer service and build reports based on SLAs, Elite identified Jira Service Management to build a high-velocity support portal.
The final piece was added by centralizing data on customers’ assets inside this portal. As Apcela already stored this data in a CMDB (as a SQL database), Elite used the app Elements Connect to integrate the already existing data inside Jira.
Elements Connect serves as a connector between the CMDB and Jira: it retrieves information on the customers & assets impacted from the CMDB to integrate it inside Jira tickets. This way, support agents get all the information they need to handle incidents efficiently.
This connection can be configured to get real-time updates, providing always up-to-date information to agents.
Cascading select-lists & read-only fields, filled automatically by Elements Connect based on the customer name
Elements Connect configuration
The final reason for the choice of Elements Connect: its native integration with the app EazyBI. As the Elements Connect custom field data gets stored in Jira, it is made possible to use eazyBI to build reports based on data coming from the CMDB. This integration was crucial to build comprehensive dashboards & have a global view of the support service performances.
With this personalized solution, using Jira Service Management combined with EazyBI and Elements Connect, they were able to automate as many actions as possible, saving a lot of time for agents, and providing a high-velocity incident management service.
Results: faster incident resolution by well-resourced support agents
The first benefit for Apcela was the centralization of all the information on their customers & networks in an unique environment for incident management.
Thanks to the external data integration made possible by Elements Connect, the support team was able to manage incidents more efficiently, accessing all key information directly inside the Jira tickets and saving a lot of time on manual actions.
As Apcela was now able to monitor everything, they could identify any incident on their networks ahead, centralize them in the portal, and therefore correct them as quickly as possible.
As proof, since this solution was implemented 3 years ago, they’ve achieved a huge improvement on SLAs: average pick up time has been divided by 20 on Apcela Help Desk.
Thanks to this implementation made by the Elite team, speed and performance continue to be the cornerstone of Apcela company.
About Elite IT Consulting Group
Elite IT Consulting Group is an Atlassian Solution Partner based in Argentina. Formed by a multidisciplinary engineering team, they developed an expertise of more than 8 years implementing, configuring, administering and automating Atlassian’s tools for very large and international companies.
After months of work, we’re happy to announce that Elements Copy & Sync for Jira Cloud has arrived. For years, Elements Copy & Sync has helped Jira administrators and users reduce manual tasks by copying, linking, and synchronizing Jira issues automatically. As Martin Lalonde, Jira Admin at Bonduelle North Americas said about Elements Copy & Sync “The biggest advantage? The automation. It makes Jira easier and faster, so you can spend time on the issue and not trying to create more issues in Jira.”
And now those same benefits are available for Jira Cloud users.
Copy recipes: the new configuration of Elements Copy & Sync Cloud
Instead of replicating everything in the Server/Data Centre version, we looked at how we could make the configuration of copying, linking, and syncing issues easier. The result? Copy recipes, which combine the settings for the source issue, field mappings, and settings for the target issue. We focused on making the app admin very user friendly and straightforward. Configuring a custom copy and synchronization of an issue can be done in just a few clicks.
Powerful Jira issue copy and synchronization options
Elements Copy & Sync recipes are highly customizable, and allow Jira admins to create copy templates to apply to different use cases. Jira admins can configure where copy recipes will be available, for example for all issues in a project or only some or just 1 issue type. Similarly, you can restrict target projects and issue types. Or leave it up to the user to pick what they need. You control how your users can use copy recipes.
In addition to copying fields, you can also copy comments and attachments. The synchronize option can be one way or bi-directional depending on your use case, and it means changes to fields, comments, or attachments are automatically updated.
Integrate into your existing process seamlessly
We know every team is different: Classic projects, Next-gen, old issue view, new issue view… Elements Copy & Sync works on all of them.
Our goal is to help teams reduce manual tasks for common processes like
- Escalate issues from JSD to Jira Software with comments and attachments synced
- Copy issues to a different project on a workflow transition for incident management
- Create change requests from a Service Management Ticket
- Create Epics or Stories from a Support ticket and sync fields
- Create Stories from an Epic and link them
- Create a linked task with a pre-configured Summary or Description
Helping Jira users reduce manual processes
We have lots of features on our roadmap that will help you reduce manual processes even further. If you missed our webinar but want to see how Elements Copy & Sync works, we have a demo walk through available on our YouTube channel. We sure you’ll agree that copy recipes are very easy to set up.
Curious? Start your free 30 day trial today!
Like many other companies, Elements has had to adapt to a new way of working together because of Covid-19.
Elements already had experience in remote work since working from home five days a month was implemented in July 2019. But a government imposed lock-down brought Elements to a new level: working from home 5 days a week for everybody! We therefore had to adapt our way of working together.
Here is my “Remote Scrum Master” toolbox and some practical tips for any agile team working remotely.
Agile ceremonies
Meeting tools
Tools: Microsoft Teams, Google Meet
As an agile company, we are used to agile ceremonies. For daily standup meetings or casual team calls, the Covid-19 lock-down didn’t require a lot of changes since we were used to having one or two team members working from home. The only difference was the number of remote colleagues.
Our main meeting tool is Microsoft Teams, but when we want every members’ webcam to be displayed at the same time (that is the case for Retrospective meetings) we prefer to use Google Meet with the Grid View extension.
Retrospective meetings
Introduction: Sprint numbers quiz
Tool: Microsoft Power Point
At the beginning of each retro, we begin by checking sprint indicators and last actions progress.
For this first part, I like to turn it into a quiz for each member to compare their sprint vision with reality.
Set the stage: Team Mood
Tool: Google Slides (with edit rights shared among company members)
Regarding the “set the stage” part of the retro, we use collaborative activities like this “Team Mood” board done with a shared Google Slides document.
Gather Data / Generate Insights / Decide what to do
Tool: TeamRetro
For the next retro steps, we tested several tools but the one which fits our needs the best is TeamRetro. We found it useful because we were able to
- show our “post-its” all at the same time
- easily generate insights, group ideas and find follow-up actions for all steps of the retrospective
Poker planning
Tool: Planning poker online
A simple and efficient tool to play poker planning like in real life!
White board
Tool: Google Slides (with edit rights shared among company members)
When we were all at the office, we used to display all sorts of information on our white boards. It was the occasion to share information with all Elements colleagues.
For instance, one of our regular displays is our “Sprint objectives poster”: for each sprint we define sprint objectives during Sprint planning. Then we create a fun poster with the name of the sprint and its objectives, and display it on a white board.
Since we didn’t have a real white board, we created a virtual one with a shared Google Slide document on which everybody can find and add information.
Newcomer integration
Integrating newcomers remotely sounded complicated, but we found tools and an organization to welcome and make new people progress and feel included as though we were together in the office.
Onboarding
Tool: Trello
We already had a solid onboarding process with a 3 week program for all newcomers. In order to facilitate it while remote, each newcomer now has his/her own Onboarding Trello.
He/She will easily find on this board:
- onboarding task checklist
- links to important wiki pages
- pictures and information on his/her new colleagues
Integration follow-up
Tool: Google Slides (with edit rights shared among company members)
On our virtual white board, we included onboarding details of our recent newcomers.
He/she can share his/her integration progress to everybody in the company by ticking of steps with colored virtual stickers.
Creating new habits for our team working from home
Some events were already in place before the Covid lock-down, and were particularly important while we were physically separated.
This is the case of our Elements Vox & Talks, which is a weekly event where all Elements members can share news, tips, or interesting subjects (read more about Vox here and Talks here).
But lock-down made us think of new ideas to bring spice to Elements’ life and to help keep links between colleagues.
Elements Confinement Painting
Tool: AWWapp
Lock-down gave us idea to begin our weekly “Elements Confinement paintings” (confinement was the official term in France for the lock-down): each Friday, everybody could express that week’s feelings on a shared drawing board.
AperoVox
Another event which appeared during lock-down is the “AperoVox” which occurred each time a newcomer arrived.
After an Elements Vox event, we organized a game for Elements team members to get to know each other.
Collaborative personal map
Tool: AWWapp
One time we did a collaborative personal map of all Elements team members.
In 20 minutes, everybody added information they knew on other Elements members (family, hobbies, fun facts, …).
Then we reviewed it together and learned a lot of interesting things!
Elements members quiz
Tool: Kahoot!
Another time, we used Kahoot! to create a quiz with questions to check our knowledge of our colleagues (“how many Elements members are native from a country other than France?”, “who is an arm wrestling champion?”).
Life after lock-down: transitioning from an all remote agile team to a partial remote team
Now that the lock-down is over (for the moment!) and some colleagues have begun to come back to office, it’s very pleasant to meet our colleagues the old way!
But that also bring new concerns: how to manage a mixed local/remote team? what are habits we can keep from this total-remote phase? There certainly are challenges in managing a remote agile team and now a partial remote team. We’re always trying new ideas and trying to implement best practices for working from home to continuously improve.
Sound like a team you’d like to join? Check out our careers page to learn more.
At Elements, we care about our company values. They go right to the heart of our most important strategy ingredient – our employees.
One of the crucial company value for us is Talk straight.
Talk straight
We value open, two-way communication between co-workers, clients and partners. We believe that being true to oneself, saying what you mean and openly sharing knowledge is the key to trust and mutually enriching relationships.
Knowledge sharing is a fundamental part of talking straight making this concept essential to us. It might seem obvious why knowledge sharing is important, but the reality is different – not all companies focus on a “knowledge sharing culture”.
Benefits of sharing the knowledge are numerous. It assures that people are more connected to others, that they are involved with information and knowledge outside of their department. We learn new skills and feel more comfortable with our existing knowledge. Elements is a open community of knowledge that we are constantly expanding.
We use many different tools and events to share our knowledge. In the article I will talk more about one specific event: Elements Talks
Elements Talks are presentations created and given by Elements team members every two weeks in our open space. This event occurs on Friday around 4 PM (France) so that our colleagues in another countries can participate. When it’s not a Talks week – we organize Elements Vox. This assures that every Friday there is a knowledge sharing event open for everyone. It’s been already a year and a half that we are holding this event with success.
Here are some key principles of Elements Talks:
Open for everyone
We encourage different topics from different teams. You don’t need to be a expert to present a subject. It can be about something you personally want to learn, a lived experience or an inspiring article that your read last week and then developed into the presentation. Here are some examples of the previous Talks:
- I recently presented “Atlassian Security: XSS attacks” talk that was inspired by the presentation I heard during the Atlassian’s App Week in Scottsdale. The goal was to make everyone aware of the security issues with which our apps are confronted and to present the recorded version to the newcomers.
- Our colleague presented “Everyone can code, even your grandmother” where he talked about existing coding frameworks for kids and teenagers and low code approach to application development.
- Another colleague presented a very interesting talk “Why we should stop playing video games… and make them instead” that was inspired by his own experience in developing video games.
- Sometimes we invite some external speakers to spice up this event. Security Expert from Thales came to our office to talk to us about “Security Awareness” in our day to day activities.
Organized in a cozy environment
Presentations are usually 30 minutes long so it is important to feel comfortable during this event. This is why we organize talks in our open space. Take your favorite hot drink, sit in a comfortable chair and if you are lucky and not late – you may still find a home made cookies on the table.
Optional
Don’t feel obliged to participate if the topic is not interesting you. Everyone can submit the topic. Keep in mind that content related to our domain (we are a software company) are more likely to interest other people.
Record it
Someone made a great presentation everyone is talking about, but you were on vacation? You just joined our company and you would like to see some previous presentations? Working remotely? No problem: we capture all our presentations and make them available. There are numerous ways of capturing a presentation, here is our current setting:
At the end of each talk, we have open questions and debates about the presented topic.
To get most things done in an organization today requires a collaborative effort. This event helped us learn new things but also reduce the communication barriers between employees to create a friction-less communication.
Larbi El Alami, senior consultant for Valiantys, leading French Atlassian Platinum Solution Partner, told us how they helped one of their major clients provide an efficient ITSM support with Jira Service Management & Elements Connect.
Context
As Atlassian Platinum Solution Partner, Valiantys provides its expertise to global companies since 2006 and guide teams during their agile transformation journey. Its consulting team’s activities go from project scoping to implementation, change management and training on Atlassian solutions.
IT Service Management (ITSM) is a frequent activity among their clients and we’ll present here how Valiantys helped a multinational manufacturing company improve their ITSM support.
The client’s IT Service team has to deal daily with the internal requests of thousands of employees in various countries around the world, on typical IT issues such as an incident on a computer, or an access request. Managing this volume of requests on a international level involved the use of a robust ITSM tool: Jira Service Management, to implement an efficient IT Service Management.
The hidden needs behind a Jira Service Management implementation
The use of Jira Service Management has 3 main benefits:
- it provides a structured client portal, separating the client side from the agent side while being user-friendly.
- it helps reduce costs, buying licenses only for agents, and allowing a free access to all users for them to be able to create directly tickets on the portal.
- it comes up with a complete native SLA management system.
However agents were facing a main pain point: the process of taking in charge one ticket was extremely long and tenious, for one main reason: the lack of information.
Each time a ticket was created on the portal, the only information provided about the reporter was his name. So agents had to leave Jira to look for all the reporter details on other tools and add manually the useful missing information in the ticket, creating data duplication. They were missing data and context, and losing time on manual actions.
As the consultant Larbi El Alami mentioned it “it was slowing down the process for Service Management agents and reducing the efficiency of using Jira Service Management.”
In the search of a solution, Valiantys consulting team used the advantage of the client of having all the data needed already available into an external data source: an user directory using LDAP. It gathered all key information about employees: contact details, but also country, business unit, position, etc.
The goal then was to get data from the user directory and display it into Jira Service Management on the agent side. That’s where Elements Connect comes into play.
Getting additional data from LDAP to contextualize ITSM requests
The app Elements Connect is a Jira add-on developed in the goal of centralizing all useful information into Jira by getting it directly from external data sources. Larbi El Alami gives us 3 main reasons why this app has been chosen for this project:
- its native LDAP management feature, making transparent the connection between LDAP and Jira.
- its robustness, especially on the big Jira instances multinational companies are working on.
- its ease of configuration, streamlining the work of consultants & Jira administrators.
The implementation of Elements Connect took 2 main steps: configuring the data source connection and displaying the fetched data in the corresponding tickets.
Once the connection is made, data retrieving is done by query based on the reporter’s name to get all useful linked information (first name, last name, email, phone, business unit, office, position). These details on the reporter populate custom fields displayed in the issue to contextualize the request for agents.
To go further in the Elements Connect implementation, it would also have been possible to sort a ticket in a specific queue or to grant it with specific SLAs depending on the VIP status of the reporter for example, status available in the user directory and added in a custom field on the ticket.
Improving request management process to decrease the time to resolution by 50%
Implementing this solution generated numerous functional benefits for IT agents:
- no more time loss due to looking for information outside Jira, and manual inputs (before, the agent had to manually enter data in 10 fields, fields which are now automatically populated thanks to Elements Connect) ;
- no more data duplication nor data entry errors because everything is fetched from another data source and kept up-to-date without any intervention needed.
Agents now have much more accurate information directly into the ticket, improving the communication with customers. A benchmark made by the client showed that the time to first response and the time to resolution were divided by 2 since the Elements Connect implementation by Valiantys, proof of a higher quality service.
Interested in working with Valiantys? Contact them here
Want to see Elements Connect in action? Visit our demo portal
At the beginning of 2019, my colleague Brice Gestas proposed organizing events called “Software Labs Lunch” (SLL) inspired by the Brown Bag Meeting concept. The main idea was to invite technical people (from Elements or not) during the Friday lunch time slot to do ~30 minute presentations about new development languages, tools, etc. It was great, but several problems appeared:
- The lunch time was used by many people to do other activities (like shopping, sports, …). Furthermore, this time slot wasn’t ideal for our colleagues who work in other countries, like Canada (6 AM it’s maybe a bit too early 😴);
- Non-IT people were “excluded” by the technical topics aspect;
- One or two months could pass without any presentation;
During an internal workshop in November 2019, we decided with Brice to rethink the SLL concept. To solve the previous points, we moved the time slot from lunch to the afternoon and opened the topic scope to any subjects. This solved our first two issues: everyone can participate. Still, a problem remained, regularity of these events. Even if the SLL main idea is to share knowledge, we can’t force people to do ~30 minute presentations, it’s not logical. That why we decided to split the SLL event in two new formats: Talks (presentations created and given by Elements team members – like the first SLL version) and Vox, which is the subject of this blog post.
Vox concept is based on existing daily interactions: discussions around the coffee machine or during lunch. It’s often here that a lot of knowledge is shared by different people on various topics. Inspired by that, Vox events takes the shape of a round table, open to everyone in the company. One after each other, participants have the possibility to share one or more subjects with everyone present. There are no restriction about the topics! Examples from previous Voxs:
- Someone presented a nice address in Toulouse: the Eurêkafé. It’s a “curiosity coffee” which proposes presentations to discover new science topics, rooms to work with a friendly environment, or just good coffee to drink with friend!
- Another person presented an artificial intelligence which wrote a Harry Potter sequel based on the previous books;
- And another colleague shared an article which explains how to avoid ATM scams when traveling abroad;
In short, every shared topic is different, depending on who is talking and the current context. In fact, not having limitations on topics allows everybody in the company to participate, regardless their position or specialty.
Furthermore, having a subject to share is not mandatory: everyone can come to the event to only listen or ask questions on the shared topics. During a Vox session, it’s common for topics to stimulate interesting questions and debates. That’s why a chairman is present to coordinate presenters and limit discussions about a topic to 5-10 minutes, in order to let everyone participate. The chairman position is often occupied by Brice or myself, but sometimes we are not available. In this case, anyone is invited to take this place.
Six months after the refactoring, we’ve really seen that these two events are appreciated by everyone in the company. The Vox gives Elements colleagues the opportunity to talk about topics which only require one or two minutes of presentation, and sometimes, they lead to a complete Talk event, where they are fully developed!
Last March we made a big announcement, rebranding from Valiantys Software to Elements. It’s been a long but successful road since we released VertygoSLA in 2009 and nFeed (now Elements Connect) in 2010, and we’re proud of how far we’ve come as an apps developer. The new identity we created around the name Elements for our suite of Jira and Confluence apps reflects our position as a software publisher, and will provide us with the platform we need as we move forward. To mark our anniversary as Elements, we’re taking a moment to take stock of our first year with our new identify. Our customers and partners are the reason we’ve been successful, and the milestones of the past year were only possible because of their continued support.
New offices for a growing team
When we announced our new name last March, our team had just 14 people and the offices we shared with Valiantys were feeling a bit small at 7,000 sq ft. Today, Elements includes 21 people, with plans to grow to more than 30 by the end of 2020. In November we nearly doubled the size of the offices we share with Valiantys (now 11,800 sq ft) with a move to downtown Toulouse.Some of our growth has even been far from Toulouse, France: Nelly has joined our support team and is based in Montreal, Canada, allowing us to provide more support during North American business hours. All our teams have grown in fact, from support to software development to marketing, but keeping our company culture and maintaining our values has been paramount as we grow. You can read more about our team and what makes working at Elements special over on our career page.
Atlassian Gold Top Vendor
When the Atlassian fiscal year closed at the end of June, we got the confirmation that we were a Gold Top Vendor. We’re proud of achieving this status for the Atlassian Marketplace because it’s proof of the value our apps bring to thousands of customers around the world. The Atlassian Top Vendor program has strict requirements around the type and quality of support offered, how SLAs are respected, and how many instances are using a vendor’s apps, so becoming a Gold Top Vendor helps us show potential app users that we’re dedicated to providing an outstanding customer experience. But we’re not stopping there: we hope to achieve Platinum Top Vendor in 2020.
Never stand still: evolving our apps and our future
Just because we have well-selling apps doesn’t mean we can rest on our laurels. We’re always looking to improve our apps, and 2019 was no exception, with several major releases.
Major releases
In June, we released a major new version of Elements Connect, which included major features like a field configuration tester, snapshot fields, and field configuration import. These new features allow Jira admins to preview their queries, optimize performance, configure fields faster so they can get their work done more easily. Elements Connect Product Manager Christophe Promé wrote about the most recent features on our blog.
We also made several major releases of Elements Spreadsheet with lots of great new features like a revamped UI, drop down lists, custom colors, and improved compatibility for clients migrating from server to cloud.
Integrated approach to innovation and security
We created in 2019 an internal research and development unit called Elements Beyond that focuses on innovation. As the Atlassian ecosystem moves into the cloud, topics like end to end testing and security are more important than ever. Our developers attended Atlas Camp and App Week to learn from Atlassian and other app vendors about the most recent developments in E2E testing and cloud security, and our focus remains on ensuring app stability and being at the forefront of developing for the cloud.
Make every interaction remarkable: connecting with the Atlassian community around the world
The launch of our Partner Program with a dedicated support portal for Atlassian Solution Partners was a major project for our first year under the Elements name. Working with Solution Partners is part of our DNA, and we wanted to provide a structured program with the resources and tools for Partners need to be successful with our apps. Our Channel Manager Cécile Sablayrolles even had a chance to do some one-on-one training with Platinum Solution Partner Deiser in Madrid, Spain.
Connecting with the Atlassian community at Summit is a highlight of each year, and our parent company Valiantys has been a sponsor of the Atlassian Summit since the very first edition in San Francisco in 2008. Last year was extra special for the Elements team since we got to reveal our new identity. We’ve been fortunate to meet customers, provide demos, and give best-practice presentations around the world in the past 12 months, and strengthening the connections not only with customers but other vendors and partners in the ecosystem has been a source of pride.
If you are headed to the 2020 edition of Summit in Las Vegas, be sure to stop by and say hello. We regularly share where we’re headed on our LinkedIn page, and we hope you’ll follow the page.
Exciting plans for 2020
We’re convinced that what we’ve achieved during our first year as Elements is only the start of lots of new exciting projects. We’ve invested significantly in developing for the cloud to match industry trends, and cloud versions of our top-selling apps for Jira will be released soon, starting with Elements Connect. We are also rolling out a Security Plan: making sure we are compliant with Atlassian Security Requirements for our Cloud Apps in production, implementing a DevSecOps process, and improving our monitoring and automatic alert systems. Thank you to all our customers and Partners; we’re eager to work with you in the coming year to continue building the best possible apps.