This year Atlassian has been named a Leader in the 2024 Gartner Magic Quadrant for DevOps Platforms. Jira, the flagship product, is a tool for planning, monitoring and analyzing team workflows within one product.
As Jira is one of the best develop tools on the market, sometimes its functionalities still won’t meet many specific requirements: as many organizations as many unique use cases. That’s why Atlassian provides a bunch of custom fields to add information specific to your team's needs.
If this is not enough, and regular fields turn out to be insufficient, then it is worth considering third-party tools, so that the process is taken care of. Atlassian Marketplace offers multiple apps with advanced custom fields that can collaborate with native features and expand their functionalities.
So what can't you do with regular fields in Jira?
The objects that comprise a Jira issue are called fields. There is a field for the summary or description. The field might be the status, assignee, priority, due date, and labels. A field is anything that you, the user, can enter on an issue. In Jira, we have regular and custom fields.
Regular fields are default, they cannot be removed and customized. These fields are an integral part of Jira and as such are subject to restrictions in relation to custom fields (such as that they can not be removed or Jira even forces the value, such as summary). For example: Summary, Description, and Priority.
Custom fields are made to maximize workflow customization through recording additional information, depending on the type of field. Users can choose from many types that determine the custom field’s format and behavior.
In addition, Marketplace has a whole range of additional custom fields when the built-in ones are not enough or have limited functions.
Example: Native cascading select has only two levels - if you need more elaborate hierarchies then you should look for a Multilevel Select solution from the Custom Fields Suite for Jira app.
According to The Institute of Asset Management (IAM), asset management is the balancing of costs with asset performance. It enables the study of the needs and performance of assets in an organization and provides an analytical approach to asset management at various stages.
Jira Service Management Assets are for premium users. So, regular users do not have a dedicated way to manage Jira assets. Custom fields won’t help us here. Using them, we cannot:
Premium/ Enterprise users can use Assets to create objects and their schemas and add attributes to each object. Thanks to them, processes such as assigning objects to an organization's employee or customer become possible.
Example: license management or equipment management.
In Assets we can also create reports - you can quickly generate a report on, for example, laptops and see who manages the object and where.
Standard fields in Jira, such as dropdowns, checkboxes, numbers, or text, do not always allow full flexibility in form design. While these fields allow you to enter different types of data, they may not be enough for more complex structures, such as tables.
If you need to enter data in grid form, which gives you a better overview and the ability to edit the information in a table, it's worth using solutions such as Table Grid Next Generation.
Of course, Jira also offers other ways to organize data, such as using forms (Forms) or tables in the description field (Description), but Table Grid provides a more interactive and dynamic way to work with tabular data.
This table provides support for various columns (summing, sorting, filtering) - you can manage multiple data in different formats (string, number, integer, dropdown select, dates, checkbox & user list).
One example of an application that Exalate describes in its documentation is project estimation. By using Table Grid, it is possible to gather all the information needed for estimation in a single table without having to use Confluence or jump between different epics.
This solution's advantage is that all the data is available in one place, allowing quick editing and review without changing the context. Unlike a standard Jira view, such as Issue Navigator, the table in the grid allows you to dynamically summarize different parameters in a single view - such as tasks, duration, resources, or status - which greatly improves the process of managing and comparing data. This makes the tool more transparent and functional when you need to view and modify the details of multiple tasks simultaneously.
Natively, you can create only two cascades with a standard custom field. However, there are plenty of situations when you need more comprehensive hierarchies, like building a service catalog on the portal or creating a process for requesting new hardware. With advanced custom fields like Multilevel Select from Custom Fields Suite, you can have them.
With this custom field, you can create hierarchies with more than 2 levels, add options in bulk, import / export, and use it on the customer portal.
This advanced custom field is also a perfect workaround for creating sub-components in Jira that are unavailable natively. If you want to keep the components hierarchy, you should do it with Multilevel Select.
This use case responds to the Atlassian Ticket.
In what use cases is multilevel select useful?
Use the Multilevel Select function to create a service catalog for customers (internal or external) to specify details in the ticket. Agents gain access to detailed information and can proceed faster without spare questions like what app version, which product, or what kind of laptop is needed.
If a company uses the Jira service desk to manage customer support tickets, a custom Multilevel Select field can streamline the incident submission process. Customers can specify the application, hosting type, and version involved in the incident.
Components or labels can be hierarchical. If you need to keep a ladder, you need a Multilevel Select. For example, tasks in the DevOps team may need a categorization. If there is an epic with Character Models, and we need Main Characters, NPCs - subcomponents are an ideal way to keep track of results and filter boards with ease. Let’s read our article about creating components and subcomponents in Jira. ✨
Among Jira permissions is level-security permission, which limits the visibility of issues in the project for users not granted this access. So far, there is no native solution that allows the security level to be set per field (for example, field Budget), not all issues.
Ricksoft has created a security fields plugin that allows you to assign security-level permissions to selected fields called Secure Custom Fields.
Thanks to a solution like that, it is possible to decide who can edit and see the field - so there is an option to hide fields for users without permission. In addition, users with permissions are informed when a field is updated, and you can also use it in automation.
Use case: HR projects with sensitive data or projects with external customer financial data—only managers should be able to see the fields and update them—the rest of the team shouldn't even see them. This way, we have confidentiality control and meet GDPR and other regulations.
One of the most popular plugins on the Marketplace is ScriptRunner—it has over 37k installations! One of the app's features is scripted fields. What makes it so popular?
It allows users to dynamically generate field values based on a script, such as calculating time differences or summing field values. The data is automatically calculated and updated.
Using scripts allows almost infinite possibilities for customization and adjustment of what you need. However, it requires skills in a scripting language (Groovy) and programming, so it’s narrowed to more technical users.
Use case: Useful in agent queues when you add a field that automatically calculates days of delay based on the due date. It helps to monitor progress and bottleneck and set priorities.
Data is crucial to resolution. Your customers can make mistakes in submitting tickets every single time, which leads to longer resolutions due to a lack of relevant data. Format mistakes or simple typos are among the problems, such as inadequate problem descriptions or incorrect categorization.
A customer may provide the wrong format of IP number, zip code, or email. That's why validating this data is a good idea, which standard fields in Jira don't allow. But as always, we have a workaround for you with an advanced custom field.
You can use an external validating field like Regex from Custom Fields Suite. This field allows you to create a custom field that validates the format you specify as required. If a mistake in the format in this field is detected on the portal when making an issue, there will be a notification to fix the mistake before saving the ticket.
You can provide your own regular expression formula or use it among many templates like SWIFT code, US Phone number, HEX color or LinkedIn profile .
Use cases: Customer service needs the reporter's phone number for shipping. The Regex field is set up to validate US phone numbers with a correct number of digits. If the customer puts more or less digits - there will be a notification to correct a value.
Regular custom fields may not be enough for your specific requirements. It is worth spending a minute scouring the Atlassian Marketplace for solutions that extend Jira's capabilities and fit your needs.
All of the apps listed in the article:
We’re here to help you implement our Custom Fields Suite in your Organizations. Find the best time and book a meeting with our experts: calendly.com/appsvio.