Page Comparison

...

Checking Data on the KPI Dashboard

1. Once Jira processor is successfully run

...

• Jira KPI’s on different dashboard appear with data.

  Image Removed

• Jira Mappings are setup with default setting provided in metadata identifier-

  Image Removed

Note: In case if user is not satisfied with default mapping user can change mappings-

• From Metadata identifier-Refer Meta Data Setup

• Or customize it manually by clicking Setting button on individual KPI.

  Image Removed

...

1. , click on Image Added to go to the KPI dashboards

2. You can access different Jira KPIs across dashboards
   

   Image Added

...

Managing Jira Field Mappings

Jira Field Mappings	Description	Steps	Image Reference
Default settings	default field mappings are associated with the Standard Jira configuration template while setting up Jira. These metadata identifiers are prepopulated when you click on 'Settings'	Click on Image Added to land on KPI dashboard Click on 'Settings' on each KPI widget	Image Added
Custom KPI level settings	override the default mappings by customizing them manually.	Click on 'Settings' on each KPI widget	Image Added
Global Jira mappings	Mappings that are global and apply across dashboards. Additional Filter Identifier Custom Fields Mapping Defects Mapping Issue Types Mapping Workflow Status Mapping	Go to ‘Projects’ list and search your project Click on Image Added to edit configuration Click on 'Mappings' Image Added Expand each section to edit and save the mappings	Image Added

...

Things to Remember

When modifications are made to the field mapping, certain fields may require the processor to be re-run in order to implement the changes effectively. Specifically, when we add or remove any mapping, the below are the mappings that require processor to run again.

Note: This is applicable for only Jira processor and Azure board.

1.Custom Fields Mapping:

The changes that we make in the custom field mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

This will be applicable for all the fields in the custom field mapping.

...

2.Defect Mapping:

The changes that we make in the defect mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

In the defect mapping this will be applicable for UAT defect values, production defect values.

...

3.Additional Filters Mapping:

The changes that we make in the additional filters mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

This will be applicable for only squads.

For any type in the squad we need to re-run the processor.

...

4.Issue Types Mapping:

Kanban:

The changes that we make in the Issue type names under Issue types mapping requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

...

Scrum:

The changes that we make in the Issue types to be fetched from Jira requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

...

Apart from the above mappings, for any other change in the mappings refreshing the dashboard is enough to affect the mappingssuch fields require the processor to be rerun

1. Global mappings: Any modifications to the global field mappings in a Jira or Azure Board configuration require the processor to be re-run.

2. KPI-level mappings: A few KPI-level mappings that require processor rerun are marked in the Settings.
   For example,
   

   Image Added

3. For any other changes to the mappings, simply refreshing the dashboard is sufficient to apply the updates.

Note:This applies only to Jira and Azure Board processors.

...