Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,146
Community Members
 
Community Events
176
Community Groups

Thoughts on using JSM intake Forms driving 100+ custom fields

Jack Brickey Community Leader Dec 18, 2022

Hello community! I'm hoping others may have dealt with a similar scenario and might share your experience and thoughts about the best practice. A client is considering using JSM and has it prototyped currently.

Scenario: Users log into a website to record test results of devices. Here are some details:

  • there are various 'sections' of tests to be performed/recorded: general (tester, date, user info, etc), main body of device, part A, part B, Software/firmware, etc.
  • each section will have various tests that will record pass/fail results and in some cases other section specific data, e.g. date part was last replaced/repaired
  • Some sections are conditional based on input
  • This is purely a use case where data is recorded. There is no Agent that responds to the issue. Once the 'issue' is created it is marked Done.

The client has the basic operation setup in JSM using Forms and it works well.

Problem (?): The client wants to be able to analyze all data. In short this could result in the creation of 100+ custom fields that would then be linked to the various Forms fields. This will allow the use of JQL or, in their case, connect to PowerBI for analyzing test results, trends, etc.

Personally I have always attempted to minimize the abuse of custom fields. Maybe this isn't a problem here.

Maybe JSM isn't the best option here or maybe it is fine.

I welcome any and all thoughts ideas comments.

5 answers

1 vote
Jack Brickey Community Leader Dec 21, 2022

All,

I wanted to update everyone on where I have landed on this topic.

After much deliberation I determined that the best option for the client is actually not JSM but rather Google Forms or Microsoft Forms. I have never used either but took the opportunity to play with it a bit and was quite impressed with the capability and how easy it is to use both.

Thanks again for everyone's thoughtful input here.

0 votes

You may want to look at Deviniti's "Extension for service desk" add on, 

https://marketplace.atlassian.com/apps/1212161/extension-for-jira-service-management?hosting=cloud&tab=overview

In particular, the "Bundled field" functionality.

https://deviniti.com/support/addon/cloud/extension/latest/bundled-fields/

That may allow you to do some of the data collection and analysis with less custom fields.

Particularly if you look at their Dynamic forms functionality as well.

0 votes
Dirk Ronsmans Community Leader Dec 18, 2022

Hey @Jack Brickey ,

I'd like to understand the reasoning of using JSM for this? Are they using the portal to register the data and thus avoiding any additional licensing cost and is that their main driver?

You do mention 

The client has the basic operation setup in JSM using Forms and it works well.

but since Forms exist on the portal and on regular issues I'd like to get some clarification on that :)

If they do use the regular issue environment as Agents you might even look in to using JSW with some testing app. (like XRay or something similar which is purposely designed and build for the management of tests and their outcomes)

Jack Brickey Community Leader Dec 19, 2022

Hey guys, thanks for each of your inputs here. I'll try to better explain the situation.

Without giving away potential proprietary information I will try to explain with a hypothetical scenario.

Background:

Company ABC provides commercial refrigerators as a service. Company ABC maintains ownership and simply leases the equipment to their customers. Customer ABC provides maintenance for the equipment. Currently, company ABC has an in-house built website that the service technicians use to record any maintenance activities.

Maintenance activities include: 

  • Monthly exterior and interior inspections
  • Quarterly exterior and interior inspections
  • Monthly Compressor inspections
  • Quarterly compressor inspections
  • Cooling calibration service
  • Interior and exterior repair service
  • Etc.

Opportunity:

My client (ACME) is working a new opportunity with ABC. One component of that is to replace the current webpage such that ABC will be able to better analyze the data associated with all of the maintenance and service activities. There are other benefits as well but that is not material to this discussion. ACME is well-versed in JSM and considers that to be a viable alternative for logging all maintenance activities. One reason for this is based on the capabilities of Forms. 

Prototype Explained:

ACME set up the basic forms needed for the technicians to log their maintenance activities. As an example, Fred technician logged into the JSM portal and choosers maintenance log as the request type. Fred is presented with a basic form one field of which is "Service Event Type". Now depending on the value Fred enters for service event type he will be presented with conditional sections each containing unique fields that require input. Part of that deals with actual tests and results. For example: T1-T2 Resistance (Pass/Fail), T1-T3 Resistance (P/F), etc.. There are about 10 different Service Event Types each present different tests, inspections or service actions.

Requirement:

ABC wants the ability to analyze the data for every field (100+).

Implementation Considerations:

Access to JSM (or Jira) directly by the technicians would not be reasonable. This is why JSM portal was being considered.

@Dirk Ronsmans , a test app addon has not escaped my thoughts. However, I'm unsure how individual tests and so forth would be presented to the technician and analyzed by ABC. My first question is whether the test cases are associated to custom fields and therefore be mapped on a form. Moreover, I'm unsure what value having such an add-on would be above and beyond JSM. Of course I state that out of ignorance I need to go preview such an add-on.


In Summary:

Company ABC wants to have a webpage where technicians can record the results of inspections, tests and Service actions. Further they want to analyze all aspects of the data and trends. JSM is being considered as an option.

I hope this added information helps paint a better picture for the audience here.

Like # people like this
Onder Ozcan Community Leader Dec 19, 2022

Hey @Jack Brickey 

Thanks for explaining the use case in a detailed way. As you mentioned, JSM seems a great fit to collect all those information, and one of the challenges is defining and managing many custom fields. I could utilize the ELK stack to analyse every field, especially Elasticsearch. In that way, every field can be indexed and visualized by Kibana later. The obvious downside is investing in another tech stack and its maintenance cost. Anyway, It is just food for thought. I hope you will come up with a brilliant solution to address the use case. 

cheers,

Onder

0 votes

@Jack Brickey -

Hey Jack:

I would agreed 100% with your general thought of minimize the abuse of custom fields.  In our env, I would always dive deeper with our users to understand more on their exact needs and then guide them through the custom fields/reporting process.

In majority of the cases, the reporting needs will be able to be supported without all of their original ask of custom fields.  Especially dealing with "text field data type" custom fields.

However, we will always be there to support our customers needs/requirements and have to make exceptions.  The key is that we are not the content owners and our users are.  

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

0 votes
Onder Ozcan Community Leader Dec 18, 2022

Hey Jake,

If I'm being honest, I don't full understand the use case. Could you please elaborate on this one?

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events