Is it possible to have different screens for same issuetype with different service desk contexts

[Jason Asker]

I have an Incident issue type, and this is used by multiple request types in service desk, such as "Problem with Software" and "Problem with Hardware".

If I have fields that are specific to "software" and other fields that are specific to "hardware", is there a way to display these fields only in the context of the service request they are created, given the workflow is the same, thus the screens are shared?

I know these can be filtered in the service request itself to the customer, but as an agent all fields are visible during the transitions regardless of the context, which when working through the workflow makes it messy.

Is it possible to apply some logic to say if service request = x, display screen x. If service request = y, display screen y ?

The only ways I can think to achieve this, is by'

a) creating separate "Incident" issue types for each context such as "Software Incident" and "Hardware Incident", then duplicating the Incident workflow so that I can apply different screens on different transitions.

b) having variations of the same transitions on the single workflow (eg, "Pending", "Pending <space>",, applying a different screen to the transition based on the context, then using a plugin such as scriptrunner to script a condition on each transition to only show if the relevant "service request" field is populated.

Surely there is a better way than this?

[Andrew Laden]

You can also look at the "Live Fields" functionality of Power scripts for Jira

https://marketplace.atlassian.com/apps/43318/power-scripts-jira-script-automation?hosting=server&tab=overview

Which makes is pretty easy to show/hide fields depending on various conditions.

https://confluence.cprime.io/display/JJUPIN/lfHide

If you go the route of separate issue types for hardware vs software, you can still have them share the same workflow, even if they use different screens.

You can also use field configurations to hide fields as well based on issue type. So they could even share the same screens but use specific field configurations.

[Mike Rathwell]

Hi @Jason Asker 

You are actually rather close to the approach and, while it's not necessarily "better than this" it isn't all that bad; just a matter of getting used to the sometimes convoluted way that Jira "thinks".

So... my $0.02 worth on an approach that has worked for me:

1. This is the hard one; step back and simplify as much as you can. Find all the commonalities and embrace them. It's easy and seductive to be extremely granular. However, when the granularity starts getting in the way, people start going around the process. <steps off soapbox>
2. Your thought of multiple issue types each of them having perhaps more than one Customer Request Type is the Right Idea. I have that for just the reason you cite; having screens/workflows/etc with relevant information for the type of task at hand. A sometimes annoying "feature" of Jira is that it only displays populated fields so, even if a screen has dozens of fields, the detail view will only show the populated ones which should be those relevant to the task at hand.
3. Your idea of conditional transitions is also a good one. If you haven't gotten it yet, do add Jira Misc Workflow Extensions (JMWE) to your system. This is one of my Swiss Army Knife addons that I insist is on any Jira instance I am responsible for. You could easily have many different transitions between two statuses with different transition screens triggered on issue type, customer request type or combo thereof. 
4. A corollary approach to the above point but a bit more advanced to work with behaviors using ScriptRunner for Jira (another staple item for when I need to get really deep and ugly with my instance) so that it conditionally displays fields based on context. The transition screens are a bit harder but you could get there from here.

Overall, there is a way to do this but do be careful of over complicating when not necessary. In my instance I use exactly the same workflow for IT Helpdesk and for Workplace Services Helpdesk. The steps taken for each of them through the process are always the same; only the context changes. As such, I have that combo of issue types, screens,  and workflow conditions to do All The Things but, even at that, it's not hugely complex.

Good luck. Trust me; originally I rather disliked JSD and attempted to NOT use it by making Jira Software do what I needed. I kept tinkering with JSD until, one day, a light bulb went on and... I love it.