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

One Screen for per Issue type vs separate screens per Issue type

felix.weber
Contributor
June 16, 2020

Hi all,

Scope: (Jira Cloud) Service Desk projects 


how do you deal with organising your screens for multiple request types at best ? 

In general there are at least 2 options:

  1. create one screen+screen scheme and use this e.g. for all ServiceRequest issue types.
  2. On the other hand you can create a new screen+screen scheme etc per Request Type

 

when you need to add a field for all issue type option 1 might be the best option. 
However e.g. if you need to add Customfield - multi-line text field only to one request type it will be shown at all others as well (if you don´t go through all request type and hide the appropriate field)

For customisations the 2nd option might be better.

Is there any best practice ? This comes again in my mind as I am setting up a new project again and facing exactly this issue again

 

cheers

2 comments

Mathis Hellensberg
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 16, 2020

Hi @felix.weber 

Usually you want 2-3 screens per issuetype. ('Create/View & Edit' or 'Create, View & Edit'). I always make sure to name them appropriately ex. ITSD: Inicident Create/View Screen. That way I can quickly locate the correct screen.

All the mapping should be done in the Screen Scheme and Issue Type Screen Scheme.

You are correct in that adding a specific field to a bunch of issuetypes at once, quickly becomes a larger task, but then again if you ever need to remove it from a single issuetype, that will be swift.

If you need the same fields on a lot of issuetypes, using the same screens is probably best, but i usually find that at some point you'll always regret not having separate screens.

Hope this helps :)

felix.weber
Contributor
June 16, 2020

Hi @Mathis Hellensberg , thanks for your input - however as we are working with SD cloud within the screen scheme setup only the view screen configuration will be used.

see also https://confluence.atlassian.com/adminjiracloud/associating-a-screen-with-an-issue-operation-776636488.html

Mathis Hellensberg
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2020

Oops, I'm really sorry, that was indeed for server only :/

Dirk Ronsmans
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 17, 2020

Hi @felix.weber ,

This has indeed come up a few times already.

Imho, 2 or 3 screens is the way to go for Issue types. Let me explain.

Initially you would want to have 

  • Create screen: clean, simple and not overwhelming when creating an issue
  • Edit/View screen: more information, specifically for the agent handling the issues or where they require to add more information.

For me (currently at least) the only reason to split this in to a 3rd screen is to create read-only fields.

E.g.

A priority would normally be calculated based on the impact + urgency = priority. Here you would not want anybody to edit the priority directly but still have it visible.

Thus, you could add the "Priority" field to the View screen but not to the Edit screen. This essentially blocks the agent to change the value through edit or inline but it is still shown on the View screen.

(little sidenote: bulk changes can still overwrite this)

Also keep in mind that Request type and Issue type are 2 completely different things :)

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events