Thoughts on using JSM intake Forms driving 100+ custom fields

[Jack Brickey]

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.

[Jack Brickey]

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.

[Andrew Laden]

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.

[Dirk Ronsmans]

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]

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.

[Onder Ozcan]

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

[Joseph Chung Yin]

@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.

[Onder Ozcan]

Hey Jake,

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