What's the best way to tag issues to platforms?

[Saagar Khimasia]

I run multiple platforms (7 to be exact) in my environment. I'd like to tag issues to a platform for ease of reporting on each platform.

What's the best way of doing this within a Service Project in Jira Service Management? It would be nice to also be able to use Jira's inbuilt reports to help me ease the burden of weekly reporting.

[Gaurav]

Hello @Saagar Khimasia 

Welcome to the community!!

In order to achieve this, you can create/ define components within the Jira Service Management and use the same for reporting as well.

The components can be defined by the Project Administrator under the project settings.

Kindly accept the answer if this helps.

[Sergei Gridnevskii]

Component is good but he needs to be a Project admin for that and filters are a little bit more complex than just searching for text

[Aaron Geister _Trundl_]

Component is usually what I have used for this. Component can be routed to owner of platform and also generates a query for all issues tagged with this Component. 

You can use Component lead to route issue to person responsible for this platform. 

Components are found in JSM on the left side tab in project settings. 

[Amir Katz (Outseer)]

Just to clarify:

1. Components are inherent feature of Jira and are not unique to JSM projects

2. You can add a post-function to assign the issue to project/component lead

3. Unlike labels, non-admin users cannot create components, which keeps the list controlled

[Sergei Gridnevskii]

1. OK, but component is not a platform. Component is a part of an application like a DLL or a service. A component can be the same for iOS and Android, e.g. business logic in Xamarin.

2. I think it is a standard functionality, no need for post function here. 

3. So in case admin is on vacation users cannot do anything. Thanks but no.

I personally hate restrictions, they may work to some extent but create more problems than solve. If user does something wrong he will be reported in history. There is no point in restricting common users in adding new platforms. If they do it wrong it can be easily fixed through bulk change.

So I am for Summary tag or for a label.

[Natali Afouxenidis]

The best way to do this is to use the Component.

If that is not an option, then an alternative is to create a custom field that you could name 'Platform'.  If you have a predefined list of platforms, I would suggest you create the custom field with the type 'Select List (single choice)' and add the predefined values. Also, you need to make sure the field is then added to all the screens of your issues.

Note, that you need to be an Jira admin to create a custom field.

[Sergei Gridnevskii]

The easiest way would be to add platform tag to Summary, e.g.

ios: Button is grayed out

Now you can sort issues in Search window by summary or filter them using text ~ "ios:".

If you later decide that you need components or a custom field - just filter them and Bulk Change.

[Marc - Devoteam]

Hi @Saagar Khimasia 

I would recommend you to use components as well.

Only users with project admin privileges will be able to add the, thus you are also able restrain the creation of these components as they are important to differentiate your platforms.

[Joseph Chung Yin]

@Saagar Khimasia -

Welcome to the community.  As you can see all of the previous responses (i.e Using Component/s, Labels, Summary tags etc...) are all great recommendation.

Another idea that you can utilize is by using the JSM out of the box custom fields - "

Product categorization or Operational categorization.  Both fields are Select list (cascading) field type.  You will need to work with your Jira/JSM administrators to populate/setup the select options (assuming you are not admins) for your JSM projects.  NOTE - each project can have its own select options contexts.  

Once the issues are created in your projects, then agent can be trained to tag them properly with those fields as defined by your business process.  Or, you can establish automation rule to set the field according to the request type at issue creation.  Lastly, you can even expose those fields to your request type forms if your users knows what to select.  So there are many ways where you can configure for the field population.

Once your issues are tagged properly, then you can simply use JQL to obtain your reporting needs.

From my experience, using custom field (i.e. select list) or component/s are preferred.  It is because you can have common set of values for issue tagging process.  In addition, if you need to change an existing value (i.e. changing "Apple" to "Orange"), it is straightforward process where you just edit the value in the custom field option configuration or edit the component/s value.  Once they are updated, all of your issues tagged with those values will be updated automatically. On the other hand,  searching against a text field is less desirable because there you don't have any nomenclature format control and bulk update issues can be difficult as you cannot just conduct partial update of a text value field's value.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Amir Katz (Outseer)]

This is a great suggestion, I was not aware of these two predefined fields.

[Amir Katz (Outseer)]

One more observation, regarding the @Sergei Gridnevskii 's suggestion:

I don't have inside knowledge of the Jira database, but I can speculate:

1. Text searches are the most inefficient as the values are not indexed

2. Any Jira entity that has a predefined set of values (components, select fields, fix versions, etc.) are indexed and thus the searches with them are fast.

3. Entities with predefined values can be used in statistics (e.g. dashboard widgets) while text searches cannot.