3 real-life use cases of how dynamic custom fields work for different Jira teams

Using Atlassian products and creating workflows, users have their unique requirements, but most needs can be summed up into four main factors that make operations match business requirements:

• automation,
• customizability,
• real-time data insights,
• indicators.

Data is the most powerful asset. Whether it’s Jira Software, Work Management, or the service desk, we need data and proper indicators to see if the process is going as planned, the bottlenecks, and how to orchestrate tasks in time. Jira is nothing more than fields with data; you have to know how to use and collect it.

KPIs are the foundation of achieving business objectives and are made of indicators.

While quantitative indicators are expressed in numbers, qualitative indicators are more characteristic of a business or process and are based on subjective feelings, like answers in employee satisfaction surveys. 

Needed quantity indicators are present in Jira, but you must find a way to gain them when standard fields are not enough. 

Various data within the issue can be displayed thanks to dynamically generated values, and they are often what managers need to make informed decisions and orchestrate tasks in controlled conditions. 

What is a dynamic generated value?

As Jira is made with different fields, standards, and custom fields, we have access to data that we already see, but we can also use advanced custom fields to gather information that is not evident. Atlassian Marketplace offers many plugins like Custom Fields Suite with advanced custom fields, and dynamic custom fields are one of those that are game-changing. 

The dynamic generated value is data that is automatically calculated based on different values. For example, we can count how many comments are within one issue or how many reporters were involved. 

How Dynamic field works? 

The dynamic field is an advanced custom field that is read-only. If you are a technical person, you probably know Jira Expression formula that this field is based on. It’s used to set dynamic values for fields within one issue. With this solution, we initialize other fields and read and analyze their values.

In short: the dynamic field has a main job: to display result of the Jira Expression each time the issue is entered

Example: Our issue has four linked issues. With Dynamic field, we want to display a number of linked issues, so the set value for this field will be 4.

Examples of values that can be displayed: 

• Attachment total size
• Days in previous status
• Completed child issues percentage
• Completed subtask tasks
• Last comment date
• Last comment author
• Last status change author
• Number of attachments
• Number of issue links
• Number of subtasks
• Parent resolution
• Parent status
• Project type
• Subtask components
• Completed

It is a dynamic content that helps users manipulate data to make workflow the most efficient. It offers extensive flexibility in automating and customizing processes. 

Dynamic field vs automation rules

In Agile, advanced personalization and automation in task management and data analysis are essential to monitor the project's progress, control the workflow, and eliminate bottlenecks – react quickly and make adjustments. 

There are two main ways of calculating and inserting a value into the field in Jira. 

1. Post function on workflow - a little bit outdated approach, very popular in the preAutomation era. The main downside is that you need to know how to create and write a post function, and it’s limited to passing.
2. Automation - a much more flexible approach that is easier to set up with a block in a low-code spirit. 

However, automation can be time-consuming and cost-generating. If you have many conditions, the operation becomes complicated and requires constant monitoring of automation execution, i.e., looking into the rule logs. Also, there are automation limits to run depending on the license. 

The dynamic field solves all of the above with automatically counted data in the form of a custom field. 

Let’s look at some popular cases of using dynamically generated values in different teams and workflows, including Software, business, and service teams, shall we? 

Dynamic custom field role in agile teams

First, let us consider which indicators might be useful to software teams. 

Let’s take two of them into consideration: 

• % subtasks done - f.e. to show how many test cases are completed in the Test Plan.
• Number of Stories in Epic - f.e. to show Epic complexity and weight when we compare different Epics

We can easily gain that data with Dynamic field that is part of Custom Fields Suite. 

Use case: Test Management

Test Lead created a Test Plan (Story) and planned test cases with a team. All test cases are put as subtasks on the board as those are smaller scenarios in the test cycle. 

Chapter Lead wants to check how Test Plans A and B are going so far. Both Test Plans consist of multiple subtasks - some are already done, and some are still in progress. 

The chapter lead wants to know in a second how much of the Story is completed without checking every single subtask’s status. Having a dynamic field with % completed subtasks is a match. The chapter lead sees the quantitative percentage of completed tests every time he enters the Story, and the value is automatically updated - he can see the progress of the process and monitor how the sprint is going. 

It’s a similar effect to that of Zephyr. This test tool shows the test cycle in %, so a dynamic field is a perfect alternative for teams not using dedicated test tools or wanting to keep it simply in one place. 

“When planning the entire test cycle and dissecting the test cases, we need to monitor the work progress in the sprint. Subtasks or shuffles in an epic are many. That's why it's good to see right away how much percentage is left in front of us for a quick assessment without a deeper analysis of time remaining and estimations.”

Karolina Zenek

Q&A Specialist

Use Case: Planning game development

The product owner planned 100 epics to complete next year with dev teams. Each epic has more or less tasks and stories, which number shows the complexity of each epic. With such an extensive roadmap, it is necessary to categorize them and plan to settle in time. To do so, you need to know how vast each epic is.

The product owner asked the admin to create a Dynamic field with Jira Expression to automatically count the number of issues in each epic and add it to the epic view. For product owners and others involved in roadmap planning, having data at their fingertips is crucial - they can see the needed value already after opening each epic. They can quickly see quantitatively whether a given epic has 3 or 12 child issues - of course, you can’t limit yourself to this one indicator. Still, it's helpful at the strategic planning level. It’s only one factor that shows epic complexity.

So, Product Owner Adam opens epic “Environment design” and sees number 5 in the “Numbers of child issues” custom field. The next epic, “User Interface,” is more complex at first sight when 14 children have issues. This way, he can verify the rest of the epic and start planning them in time, keeping in mind that issues are not always comparable. 

Service desk agents with dynamic generated values

When it comes to incident resolution, time and details count - there is a need for real-time calculated data. Agents need to know ticket complexity immediately to set the priority and scale. Instead of searching, hopping between issues, or asking customers or other agents, the incident summary can be available right in the ticket. 

What indicators can be helpful for service desk agents? 

• No. of external comments for issue
• No. of internal comments for issue
• No. of attachments 
• No. of linked issues
• No. of engaged users -  Obserwowanie ilości zaangażowanych osób / agentów w ticket może być pomocne w zidentyfikowania zgłoszeń które są trudne (bo np. kilka agentów na nim pracuje), długo trwają (znów, wiele agentów zaangażowanych w czasie) lub złożonych

With this data, we have a ready Incident summary, which allows service desk agents to know what they are dealing with and how to approach ongoing incidents.

Use case: Incident Summary 

Agent Phill got a ticket CUS-189 to resolve. He needs to assess its complexity first to know how to approach it. Dynamic field custom fields that comments count are added in this project screen, so after opening the ticket, he sees that there are 5  comments. Also, the team uses a Dynamic field to count attachments and linked issues, so Phill also sees the number of them. Having those numbers, Phill right away knows, that this incident is bigger and it can be global. He can immediately judge by the linked issues that it is not a single incident and is more complex, occurring among multiple reporters. It surely can take longer, so Phill can plan more hours to deal with it. 

Thanks to the Dynamic field, Phill has an incident summary in one place and everything he needs to determine issue complexity and prioritization.

Human Resources teams with dynamic content 

Dynamic content is helpful for the business team as well. For example, the HR team, when dealing with onboarding, has a very complex, long list of tasks to manage in a specific time. There is a need to monitor progress. Onboarding is a complicated process that requires a meticulous approach because it depends to some extent on it the future and further performance of the new employee.

What indicators can be helpful for the HR team?

• Completed child issues in % 
• Parent status

Use case:  Onboarding process

Anna, the HR project manager, is monitoring the onboarding process. It’s a very hectic time, as the company is growing, and onboarding wasn’t for one person but for five simultaneously. Anna has to monitor all five processes and ensure that they are going strictly with a plan. 

As there are many child issues on the Kanban board, she decided to use a Dynamic field custom field to evaluate the level of work efficiently. On each story, she has a custom field with a number of completed subtasks in %. So she also knows at what stage each newbie is onboarded. 

When a project like onboarding consists of more than f.e. 15 subtasks, which also can increase for each use case, the percentage summary of completed child issues perfectly summarizes the task's progress. Also, when you see that there is less % than in other stories, you can react faster and spott bottlenecks. 

What Anna gains - how it improved her project:

• Transparent data
• Quick identification of missing deadline
• Faster spotting bottlenecks
• % process of onboarding processes

Key takeaways: 

Custom Fields Suite allows Jira users to take most of the information already gathered. Using a Dynamic field is one of the ways to automatically put values based on different fields in an issue - to make needed data at your fingertips without checking, scrolling, waiting, or hopping between views. 

Benefits of calculated custom field: 

• Real-time data without manual calculations
• Saving automation run when possible
• All data at one place in Jira - on issue view
• Ready-to-use Jira Expressions 
• Works like a native custom field 

Use the data you already have with the computed custom field. Ask your admin for a free trial and explore the power of Dynamic field and other advanced custom fields with Custom Fields Suite.