Community
Q&A
Customer Service Management
Questions
Best practice for adding a Product field in Customer Service Management?

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

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 B) 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!

1 answer

3 votes

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Dave Mathijs likes this

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Kevin Maskell-Moody likes this

Thank you. That helps reinforce my understanding of Services, and see how and when to make these other design choices. Extremely helpful.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Suggest an answer

Was this helpful?

Thanks!

Customer Service Management

DEPLOYMENT TYPE

CLOUD

PRODUCT PLAN

PREMIUM

PERMISSIONS LEVEL

Product Admin

Forums

Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

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

1 answer

Suggest an answer

Was this helpful?

Thanks!

DEPLOYMENT TYPE

PRODUCT PLAN

PERMISSIONS LEVEL

TAGS

Atlassian Community Events