Field Suggestion - better handling of Serialnumbers of products in JIRA issues

[s_weber]

Dear Community,

We are seeking a better way to handle serial numbers from devices in our JIRA issues in the cloud.

We have multiple complaint projects where, in some cases, one issue relates to a single unit and serial number, while in others, multiple units and serial numbers can be associated with a single issue.

Currently, we manage this using a short text field, but this approach has significant drawbacks, especially when entering multiple serial numbers. As it is text-only, we have limited options for validation and guiding users on how to properly add one, and especially multiple serial numbers.

Ideally, we would like a field similar to labels or components. This would allow for autocomplete recommendations if a value already exists, and enable clean separation of values during data entry, which would greatly assist with queries later on.

We have explored all available system fields and checked the Forge Fields app from Caelor, which could work, but Forge still has limitations with basic JQL queries.

We also considered Scripted Custom Fields but couldn't find a viable implementation

So we are reaching out to you, likeminded experts for ideas💡

🎯The solution should check the following boxes: 

• Setup one new field for hosting all serial numbers (currently we have over 100.000 issue containing data serial numbers)
• Restrict per project if one, or multiple serial numbers can be entered
  • possibly via Scriptrunner validation or behaviors, depends on field and compatibility
• Guidance and validation of the user during data entry
  • Validation of serial number input structure (Scriptrunner validation or Behaviors ✅)
• Cleanly separate each validated value entered
• Allow users to query for serial numbers via Basic JQL
• Compatability to multiple Apps
  • eazyBi, Structure, E-Mail this issue, JSU Workflow, Jira Automations, Scriptrunner and Xporter

Let me know if you have any additional questions and we would be grateful for any input here 😊

Thanks a ton!
Sascha

[Mathew Lederman]

@s_weber It sounds like JSM Assets would be a perfect solution to your problem.

• One custom field
• Can be configured to allow single or multiple entry per project in the custom field context 
• I’m not positive on the full field validation part, but you can definitely set it as a number field so text would not be allowed. Could use other methods to validate entry
• Cleanly separate each asset entered
• Most apps now support assets
• Querying for assets via Basic search works well. Via JQL it unfortunately does not work as well

Biggest issue is this would require additional licensing if you don’t currently use Jira Service Management as a core tool. However, you can license it at a much lower number than your Jira user count if appropriate.

[s_weber]

Hi @Mathew Lederman ,

thank you for taking the time to assist here, I really appreciate it!

We did think of JSM, as we already use it for another process (not full Service-Management yet) with a 5 agent Premium license. 

However, we see three major drawbacks: 

1. The new limit of 50.000 Objects
   1. the +100.000 issues contain around 60.000 individual serial numbers, so we would already exceed this limit. 
   2. Additionally we plan a full JSM integration and would add here around 30.000 IT-Assets
   3. So in total it would be quite an expensive case
2. Basic search with an Asset-based-field requires AQL input
   1.  
   2. It only works "well" in JQL, however, here it confuses the basic user as they see the CMD reference ID instead of the value they initially searched for and selected
      1. 
3. App compatability
   1. eazybi is possible, but the dataset is seperate and difficult to combine
   2. structure does not support any assets (not even to display as a column)

So, it was the obvious and initial idea, however, the drawbacks we experience daily with our other implementations are too huge, to roll it out for a large target audience affecting around 20 projects.  Mainly because a proper integration of the basics is still missing 🙄

Thank you again. Maybe someone else has an idea for a different approach. If we find one, I will definitely share it here!

Sascha

[Kelley R]

I'd second assets. they have some kind of volume discount for extra objects available you might be able to work out with your rep, especially as it sounds like you need very minimal attributes per object. "*To view details on volume discounts for Assets and Virtual Service Agent, please visit this page." https://www.atlassian.com/blog/announcements/jsm-cloud-pricing-packaging-update 
Otherwise, it would come out to about 2500 extra a month, which is quite a bit, but that really is the best way to handle this. 
 https://support.atlassian.com/jira-service-management-cloud/docs/manage-your-bill-for-extra-objects-for-assets/  
That said, the roadmap has some more improvements to assets happening in the next 6 months, so maybe come back to it next quarter and see if the limits have changed or anything. 
I will add that the compatibility with other apps is a harsh shortcoming of assets as it stands now. 

[Mathew Lederman]

Basically all of JSM is better in Datacenter than in Cloud. I've shared LOTS of feedback with our managed services team, CSM, and the JSM and Assets team leads at Atlassian Teams '25 as this was an incredibly disappointing discovery after our migration to cloud.

I am hopeful that the teams are actually working to improve the tool rather than release new useless features like new nav.

[s_weber]

Thank you @Kelley R ! The case currently fails due to 3 factors, one is only the potential cost. but you are right, I checked what you shared and I was entirely unaware of this. 

So thank you a lot! This may help in the future, but the entire use case fails at the Basic search. We do manufacture goods, so we have a lot of simple-minded users, which do require simple and straightforward operations.

I will keep an eye out for the future. Thank you as well for taking the time!

[Josh McManus]

It sounds like a custom Labels field would suit your needs. You can create a new field that is a Labels type field and it acts the same way as Labels. None of your serials will be able to have spaces in them, but if that meets your needs it seems like an ideal use case. This doesn't solve your project restriction requirements or the validation requirements, but it does seem like Scriptrunner could help with those pieces like you mentioned.

[s_weber]

@Josh McManus , I literally overlooked that this field also exists in the cloud! 😁

I relied on my memory knowing it from server, but never noticing it in the cloud...

I just tested, and I know search will be great, compatibility will be great and guess what, the validation for single entry and the structure of the unit serial also works!

Now I was able to test this really fast thanks to Scriptrunner Leap AI!

I gotta say a big thanks Josh! I really love when the solutions are native, simple and obvious. Those are the best 🙌

You helped us greatly! Let me know if you ever need any help.

Best regards

Sascha