nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practice for adding a Product field in Customer Service Management?

alba_vendrell

Hello!

We're creating a service ticketing tool with Customer Service Management (CSM), and I'm currently customizing everything on the board. I'd like to ask if anyone can suggest the best practice for the following scenario:

I want to have a field (for example, a dropdown) where I can select which of our products (e.g., Product A or Product a ticket refers to.

At the moment, I'm using the default Labels field to indicate whether a ticket is for Test, Production, POC, and so on. I considered adding the product information there as well, but I think having a dedicated field would be much better. It would also allow customers to select the relevant product (if I can figure out how to link it!) when creating a ticket through the customer portal, which we don't use yet but plan to in the future.

I've been looking into Custom Fields in the Jira Administration settings, but I'm still unsure about the best way to implement this. I thought I'd ask here to see what the recommended best practices are

Thank you in advance!

Accepted answers

Kris Dewachter

Hi @alba_vendrell ,

You have several options.

1. You can create a custom field (dropdown) which lists your products. You can put this field in the request so customers can use it in the portal

2. You can setup an schema and objects in assets for your products. This is a bit more complex to setup, but will give you more options later if you want to store additional information for the products. Most of the time this is extra information that is useful for the agent.

3. In JSM, you can also use "Services" for this. This is also a solution build on Assets, but has some default functionality already available.

I would not use a label for the "Test / Production / POC" value. It's better to also create custom field for that.

Labels has the disadvantage that it is not structured and allows anyone to add any value. You could end up with different labels for the same thing (ex. Production, Prod, PRD, ...)

Best regards,

Kris

All comments

Kris Dewachter

Hi @alba_vendrell ,

You have several options.

1. You can create a custom field (dropdown) which lists your products. You can put this field in the request so customers can use it in the portal

3. In JSM, you can also use "Services" for this. This is also a solution build on Assets, but has some default functionality already available.

I would not use a label for the "Test / Production / POC" value. It's better to also create custom field for that.

Labels has the disadvantage that it is not structured and allows anyone to add any value. You could end up with different labels for the same thing (ex. Production, Prod, PRD, ...)

Best regards,

Kris

alba_vendrell

Hi @Kris Dewachter

Amazing! Thank you for the detailed information and the extra feedback! I'll migrate the labels to custom fields then

I think I'll proceed with the first option and, in the meantime, investigate the other two.

Best,

Alba

Kevin Maskell-Moody

Hi @Kris Dewachter

Correct me if I'm wrong, but I still believe option 3 is the intended method for capturing all incidents, etc. related to a service. I have not continued down the rabbit hole to see how this all aligns with release notes, service status, etc. And I'm unsure how CSM may have changed that.

Can you elaborate on options 2 and 3 and how that information can be used in broader product/service reporting? Or feel free to point me to clearer guidance on this. I have yet to find clear guidance here.

Thanks in advance.

Kris Dewachter

Services is probably the strategic direction Atlassian is pushing, especially when incidents, changes, problems, ownership, dependencies and operational health all need to be linked.

Option 2 (Assets)gives you a lot of flexibility, but you need to design and maintain the object schema yourself.

You create Product or Service objects.
Those objects can store metadata such as owners, support teams, documentation links, environments, vendors, lifecycle status, etc.
Tickets can then reference those objects through an Assets field.

Option 3 (Services) is a layer built on top of Assets.

A Service becomes the central entity that incidents, changes, requests and operational activities relate to.
Atlassian already provides some service-centric capabilities out of the box.
You get a model that is much closer to how ITSM teams typically think about service ownership and operational reporting.

For a small number of products, a simple custom field is often sufficient. However, if the goal is broader reporting such as:

"How many incidents impacted Service A?"
"Which changes affected Product B?"
"Who owns this service?"
"What is the operational history of this service?"

then I would start looking at Services (and therefore Assets).

It depends on what you need:

You need a simple categorisation field? → Custom dropdown.
You need additional metadata about products/services? → Assets.
You Need a service-centric operating model with incidents, ownership, dependencies and operational reporting centered around a service? → Services.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management

customer-service-management