In today’s dynamic business landscape, maintaining effective ITIL practices is crucial. However, integrating real-time monitoring through informative dashboards elevates this importance even further. In response to inquiries from the Atlassian community, this article will demonstrate how to create custom fields and automation rules for commonly requested Affected Service attributes like Name, Tier, and Dependent Services in Jira Service Management. Subsequently, we will provide several sample Incident reports for Affected Services generated with the Performance Objectives app.

The recently introduced “Reports for Assets” dashboard template by Atlassian presents a different perspective compared to our solution. “Reports for Assets” is Object-centric, displaying data related to your Objects and their associated issues. In contrast, our approach is Issue-centric, drawing insights from issues that reference featured objects and services (only if configured). For instance, while we can identify the number of issues reporting downtimes with the DNS service, pinpointing when the DNS object was initially created is not feasible.

Notably, our method allows reporting on affected services without the need for the Administrator role, unlike Atlassian’s reporting, which restricts this capability to Jira and Site Administrators for safety reasons. We anticipate that Atlassian will introduce powerful reporting capabilities for Asset management, and we eagerly look forward to further developments in the near future.

In this article, we assume that you have already configured your service schema with Services for your ITSM projects, and that they are selectable in the field “Affected Services”. If you haven’t done this yet, you can find more information on the official Atlassian page: What are services? | Jira Service Management Cloud | Atlassian Support

Let’s get started!

To transform the distinct attributes of Service – ‘Name’, ‘Tier’, and ‘Dependent Service’ – into identifiable fields for reporting, it’s essential to incorporate custom fields that utilize your Affected Services data. This step becomes necessary due to specific constraints within the Jira API.

To add a new field of type “Labels” and associate it with the project where you intend to use it, follow these steps:

⚙️ → Issues → Custom fields → Create custom field

Navigate to the project settings in Jira Service Management.
Click on “Issues” and then “Custom fields”
Select “Create Custom Field” and opt for the “Labels” field type
Name the field “Service Name” or any other suitable name, and save the changes
Optionally, associate this new custom field with the relevant project by selecting the project under “Contexts” during the field configuration
Repeat the steps for the remaining fields by selecting a different name for Step 4 (Affected Tier, Affected Dependent Service)

To prevent accidental edits of the field, we don’t recommend adding it to the screen of your projects.

For a visual guide, you can refer to the video below:

To display Services through reporting gadgets on your Jira dashboard, you'll need to create Jira Automation rules using the custom 'Labels' fields you've just set up. Follow these steps:

Navigate to your project's left-hand menu, then go to Project settings → Automation → Create Rule
For the Trigger, choose "Field value changed"
Under Component, select "Edit issue Field" → "More options" → "Additional fields"
In the "Additional fields" section, remove any existing text and insert the following codes for each rule:

Rule for the "Affected Service Name" custom field:

In the provided code, the first field corresponds to the 'Labels' field (Service Name), and the second field represents the Service (Affected Services). The 'Service Name' will adopt the same name values as those in the 'Affected Services' field. The rest of the code processes the Object list by separating it into an array of values and removing any empty spaces between them. Rule for the "Affected Service Tier" custom field:

Rule for the "Affected Dependent Services" custom field:

In the code, the smart value '' returns the list of services that this issue's services depend on. If, for any reason, the code isn't working as expected, please ensure that you haven't included any spaces or extra characters while naming your custom fields. Alternatively, you can refer to the fields using their unique field IDs. If you prefer using the custom ID of the field, replace the field name with the notation below, where 'X' stands for the unique ID of the field.

customfield_X

To find the ID, navigate to your Custom Fields and select the ‘Edit Details’ option from the 3-dot menu of the respective field. The ID is visible at the end of the URL. In our example, the field’s ID should be displayed as customfield_10104 within the code.

Handling Issues without Dependencies

When testing the rules, you might notice '[]' in the 'Affected Dependent Services' field within the screen or reporting apps. These square brackets indicate an absence of dependencies for the selected services, meaning they are not dependent on any others.

If you wish to visualize issues with no dependencies in a more comprehensible way on a chart, you can add a second 'replace' method. This will result in two 'replace' methods in the script, like this:

You have the flexibility to adjust the replacement value to 'Independent' or any other term that aligns with your preferences.

For a visual demonstration, please refer to the video below:

We strongly advise monitoring your automation rules for potential errors. Even a minor and unintentional keystroke, such as pressing the ‘space’ key in the wrong location, can cause a rule to malfunction, resulting in data gaps in your reports. If you encounter such an issue, follow these steps:

1. Deactivate the problematic rule.
2. Address the identified problem.
3. Activate the affected rule(s) manually one time by adjusting the trigger from ‘Field changed’ to ‘Scheduled,’ then re-enable the rule. Initiate the rule and wait for its completion.
4. Once the manual execution is done, switch the trigger back to ‘Field changed’ after verifying that all data from manual execution has been included in the requests.

The same approach can be applied to older open requests if automation rules weren’t in place when they were created. You can easily use the ‘Scheduler’ trigger for these older requests using JQL. For example, this can be useful for all open tickets created before the introduction of custom fields. Keep in mind that manually executing rules may not align the historical data on custom field value changes with the issue’s creation date. This difference should be taken into account when reviewing the outcomes of manual executions.

For the manual execution of the rules, refer to the following video guide:

Below, you can review a sample Incident report created using the Heat Map gadget from the Performance Objectives app. This report displays the “Number of issues by Affected Service Name and Reporter.” Using this report in Jira Service Management will enable you to gain insights into your incident management process, optimize resource utilization, and improve the overall efficiency of your service delivery.

Here is a video demonstrating how to create various incident reports using Performance Objectives’ Tree map and Heat map.

Note: Your dependent services are indicated within ‘[ ]’ and are based on the Service in question. If a service affects two or more other services, they will be visualized as one label value separated by a comma and a hyphen “-”. For instance, in our case, the Print service relies on the [Hardware,-Firewall].

We’re committed to continually enhancing functionality. Keep an eye out for our upcoming blog posts and app updates. Explore other essential reports and KPI examples you can build on your Jira dashboard with Performance Objectives: Charts for Jira app. To learn more about all the app features, please refer to our Documentation.

Sometimes the default fields in Jira can’t tell the whole story. By adding custom fields that you can control with Jira Automation, you can help your company uncover more Jira reports that could enhance the performance of your team using the newly collected data.

Explore this list of sample Jira custom fields in JSM to enhance your team’s performance tracking. Additionally, discover ideas for building Jira reports using these fields.

Here are 2 sample custom fields for your QA team in Jira Software:

You can easily track other Jira data, such as Review Iterations, Reviewed By, Reopen Iterations, Reopened By, or anything else you feel would best suit your workflow. We provide a comprehensive library of KPI examples for your Jira dashboard for inspiration.

Creating new custom fields in Jira is easy. Navigate to the upper right cogwheel, click on Issues, select Custom fields, choose Create custom field, and search for the right field type. Configure the Name and description of your new custom field, and associate the field with a screen and project of your choice.

To gather data from your new custom fields, you can employ Jira Automation rules or integrate additional Post Functions into the Workflow events of your project. This article will thoroughly explore both options. It's crucial to highlight that the second method involving post functions comes with a higher risk of workflow disruptions. Hence, we strongly recommend backing up your workflow or opting for Jira automation as a safer alternative.

Here are the steps you need to follow if you choose Jira automation: Navigate to your project's left-hand menu, go to Project settings → Automation → Create Rule.

Please be aware that these settings are for demonstration purposes, allowing for the visualization of the process. When implementing your rules, choose transitions that are relevant to your workflows.

At the end your rules should look like this:

Here’s a step by step video of the process:

Here are the steps you need to follow if you choose Workflow Post Functions: Navigate to your project’s left-hand menu → Workflows. Select the workflow(s) to which you wish to apply this functionality. In our example, we edited the “Start progress,” but you can choose any transition you prefer. Add a Post Function → “Update Issue Custom Field” → click “Add.” In the “Post Function” section, add the following rules:

Whether you opt to achieve the desired outcome through Workflow Post Functions or Jira Automation, the end result should be identical.

Getting close to your Jira automation limits.? Check out our 7 Ways To Stay Below Your Jira Automation Usage Limits article.

Follow the three straightforward steps detailed in the article to create new custom fields and gather Jira data using automation or workflow post functions. This will enable you to build customized Jira reports, leveraging native Jira reports and gadgets or utilizing the various charting and reporting tools available on the Marketplace. You can also export this data to spreadsheets and other external tools for further analysis.

Below are examples featuring the Performance Objectives app utilizing the sample custom fields demonstrated in the article.

However, leveraging automation and custom fields ensures the collection of data from the day of their creation. Acquiring historical data may necessitate script writing and can occasionally pose risks to the integrity of the associated workflow.

In contrast, Performance Objectives for Jira stands out as a robust tool that supports a diverse range of charting and reporting features, dynamic and custom fields, metrics, target calculations, and more. The app goes beyond the demo fields presented in this article – such as Test Iterations, Tested by, and Support started – capturing a wealth of historical Jira data. Importantly, all this information can be displayed within the app without the need to create custom fields, as illustrated in the examples below:

You can effortlessly monitor your test iterations using our metric “Cycles in Status” by choosing the “Testing” status. Opt for “Display by” Sprint to gain a better understanding of your performance across different sprints and identify trends and patterns in the testing process.

Another readily available metric in the Performance Objectives app is the “Number of issues over time in status”. In this sample chart, we see the open issues in the “Testing” status, displaying the x-axis by Status Change Date and grouping the bars by Assignee (history). This allows you to identify team members who are frequently tasked with testing, providing insights into workload distribution and helping with resource allocation.

Another valuable and readily available dynamic metric in the app is “Time Between,” allowing you to monitor the duration it takes for issues between events. In our example, we’re measuring the average time from creation to work in progress. We’ve opted for “Components” in the “Display by” option to enrich data insights.

Most importantly, with this app, you can analyze historical Jira data effortlessly and begin gaining insights for past periods for a variety of Fields and Metrics as soon as the app is installed.

Built-in Jira automation provides an easy-to-use “no-code” capability, requiring just a few clicks to set up an automation rule, undoubtedly earning its classification as “accessible and user-friendly.” In recent years, it has alleviated the burden of manual work, intricate configurations, and the need for specific expert knowledge in scripting for example. However, on November 1, 2023, Atlassian introduced a new Automation packaging model for all Jira Cloud products, catching many users off guard.

As avid users of the automation capabilities across Jira, we faced the challenge of adapting to the new automation limits. This situation prompted us to reevaluate automation tools and methods that had been set aside in favor of Jira automation, thereby avoiding the necessity of upgrading to a higher tier without surpassing the limits. We have compiled a list of actions Jira admins can take to optimize their existing automation rules and have included some non-affiliated third-party, external or out-of-the-box tools — each with its own associated benefits, disadvantages, and costs. Stick around until the end to find a comparison table detailing each suggested solution.

Begin by identifying rules that consume the majority of your monthly Automation quotas. You can track usage per Jira product and individual rules by visiting the automation space in your global administration settings > Select System > Automation rules > Select Usage Tab. This step provides a clear overview of your current usage and informs subsequent optimization efforts.

Review existing rules for possible optimizations. Ensure that rules align with best practices, avoiding issues such as running too frequently, involving obsolete projects, or including unnecessary users. Consult Atlassian’s guidelines on optimizing automation rules for valuable insights. Best practices for optimizing automation rules | Cloud automation Cloud | Atlassian Support Here’s an example on how to reduce the execution frequency of a rule by using the right Trigger and conditions: The problem with this rule is that it sends email notifications for every change of an issue, leading to overly frequent and unnecessary executions.

Here’s the solution: We modified the trigger from “Issue updated” to “Field value changed” and implemented a conditional block to verify if the issue matches the desired issue type. After the modification, the rule now runs only when necessary, resulting in a saving of 50 runs per month compared to the original rule.

Consider using Workflow Post Functions. These functions can be triggered by issue creation or issue transition (change of status) and may prompt actions such as updating fields, generating change history, adding comments, or sending email notifications. Resource link: Configure advanced issue workflows | Atlassian Support. However, Workflow Post Functions come with limitations and pitfalls, such as reduced visibility over your workflow and the risk of breaking workflows. By design they have just 2 event-based triggers (‘Issue created’ , ‘Issue transitioned’) and can execute only 16 actions, in contrast to 42 and 38 offered by Atlassian Automation. Despite these limitations, being built-in, they come at no additional cost. Example of a post function: Upon transitioning to the “Done” status, set the Resolution to “Done.”

If your automation task consists mostly of scheduling the creation of recurring tasks, the Atlassian Marketplace offers a variety of third-party scheduling apps, helping automate the creation or duplication of repeating tasks with ease. Apps like Issue Scheduler provide a no-code solution for quick and easy creation of issues, based on templates you set. Other apps, such as Priority Scheduler, are more dedicated to updating fields on a schedule, such as changing the priority if the due date is close.

A few other similar apps:

• • STAGIL Issue Templates – Schedule, Create and Link
  • The Scheduler
  • Repeating Issues

Consider utilizing automation pioneers such as “JMWE (Jira Misc Workflow Extensions)” by Innovalog and “ScriptRunner for Jira” by Adaptavist. These third-party apps offer advanced post functions, customizable scripts, and additional features, providing a level of flexibility beyond what is achievable with native Automation or Workflow Post Functions. However, potential drawbacks include a steep learning curve and the necessity to grasp a programming language named “Groovy” (ScriptRunner) or the scripting/templating language “Nunjucks.” (JMWE) It’s important to note that these add-ons come with a cost for teams exceeding 10 users.

There are other apps similar to JMWE and ScriptRunner, including:

• Jira Workflow Toolbox by Decadis AG

• Power Scripts – Jira Workflow Automation by Appfire

• Workflow PowerBox – an automation suite by Almarise

There are many more we have not tested. Please note we do not have any sponsorship or affiliation with the mentioned companies and their products.

Here are two examples of automation rules created with JMWE and ScriptRunner:

If you have an experienced integration team in-house, you may consider using external apps such as Zapier or UiPath. Both tools offer a wide range of integrators and provide visual tools for managing your automation workflows. They support AI features and utilize more common scripting languages like Python, JavaScript, VB.NET, and C#. However, it’s essential to acknowledge that departing from the Atlassian ecosystem and resorting to external tools adds complexity to the automation process and incurs additional costs.

You can attempt to replicate the capabilities of the tools and apps we already mentioned by creating the functionality yourself within your own external infrastructure. This involves making POST or REST requests, listening for webhooks, and implementing programming logic, offering another approach to achieve your automation goals. However, this may necessitate additional resources, effort, development work, entail increased risks, and will require maintenance by employees with specific level of technical expertise and domain knowledge.

Please note that the features and capabilities may be subject to modifications by Atlassian and/or the respective app developers and by the time of reading this there could be added/removed features.

Navigating the new Automation packaging model demands a strategic approach. Opting for alternatives to Jira Automation undoubtedly involves increased complexity, additional effort, and potentially higher costs. Therefore, conducting an audit and optimizing your current automation rules is crucial. We trust that our article has assisted you in selecting an approach that aligns seamlessly with your team’s needs and resources, guaranteeing a smooth and efficient automation experience in Jira.

Jira Service Management’s native asset and configuration management tool, Assets, enables tracking various assets, configurations, and resources, providing valuable insights into relationships between applications, services, and infrastructure. Available for JSM Cloud Premium, Enterprise, and JSM Data Center subscriptions, it offers a comprehensive view of your IT ecosystem. This article demonstrates how Jira users with access to the Assets tool can create insightful reports based on Asset Objects. We’ll guide you through the process of creating a new custom field, using an Automation rule, and generating a sample report with the Asset Name field in Performance Objectives: Charts for Jira.

You will add a custom field that uses your Asset information to convert the unique object ID of the Asset into a recognizable Name for reporting. This is necessary because of certain limitations in the Jira API.

In this tutorial, we assume that you have already created your asset schema and established a custom field connection to your JSM project. If you haven’t done this yet, you can find more information on the official Atlassian page: Set up the Assets objects custom field. Let’s get started!

To add a new field of type “Labels” and associate it with the project where you intend to use it, follow these steps:

⚙️ → Issues → Custom fields → Create custom field

1. Go to the project settings in Jira.
2. Click on “Issues” and then “Custom fields.”
3. Select “Create Custom Field” and choose the “Labels” field type.
4. Name the field “Asset Name” or any other name that suits your needs and save the changes.
5. Optional: Associate this new custom field with the relevant project by selecting the project under “Contexts” while configuring the field.

To avoid incidental edits of the field we don’t recommend adding it to the screen of your projects.

For a visual guide, you can refer to the video below:

To display your Assets in reporting gadgets, you must create an Automation rule using the "Labels" custom field you just created. Follow these steps:

1. Navigate to your project's left-hand menu, then go to Project settings → Automation → Create Rule.
2. For the Trigger, choose "Field value changed."
3. For the Component, select "Edit issue Field" → "More options" → "Additional fields."
4. In "Additional fields," remove any old text and paste the following:

In the provided code, the first field represents the "Labels" field (Asset Name), while the second field represents the Asset objects (Office Equipment). The "Asset Name" will be assigned the same values as the "Office Equipment" field. The remaining part of the code processes the Object list by separating it into an array of values and removing any empty spaces between them. If, for any reason, the code does not work as expected, please double-check that you haven't left any spaces or extra characters while naming your custom fields. Another solution would be to refer to the fields using their unique field IDs instead.

If you want to use the custom ID of the field, replace the field names with the notation below, where "X" is the unique ID of the field.

customfield_X

You can find the ID if you open your Custom Fields and click on "Edit Details" option of the 3-dot menu of the field. The ID will be at the end of the URL. In our example, the field's ID should appear as customfield_10104 in the code.

For a visual guide, you can refer to the video below:

Ensuring that the newly created ‘Asset Name’ field is populated with relevant and meaningful data is crucial for your reporting needs. Your team can easily accomplish this during their day-to-day work activities. With the ‘Asset Name’ now available as text field type, you can use it for Display by, Group by, and Stacked by data view options in the Performance Objectives: Charts for Jira app. This opens up possibilities for creating visualizations such as Stacked Bar Chart to effectively display the most requested Assets within your specified timeframe, or Venn diagram, to illustrate intersections of different assets.

Explore other essential reports and KPI examples you can build on your Jira dashboard with Performance Objectives: Charts for Jira app.

To learn more about all the app features, please refer to our Documentation.