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,298,323
Community Members
 
Community Events
165
Community Groups

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

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

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 :)

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

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

Dirk Ronsmans Community Leader Jun 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
Community showcase
Published in Jira Service Management

Coming Soon: Insight Changing to Assets

The 2020 acquisition of Mindville added powerful asset and configuration management capabilities to Jira Service Management in the form of Insight. Following the completion of that integration, custo...

267 views 2 9
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you