It might be challenging to change the behaviour of the Customer Request Type, as it is currently being enabled after knowing the Issue Type.

Atlassian: Have you considered the possibility of building a solution based on cascade select custom field? (Issue Type > Customer Request Type)

Same here - this is crazy! This, along with JSD-270 are deal breakers for us.

Atlassian - please provide a response. This should be a simple change I would have thought?

The user is a JSD agent and is raising the ticket on behalf of a customer in the JSD project

The above is our scenario.

Not having the field on the Create Screen is itself most inconvenient but we can add the field using the inline edit after the issue is created. However the field cannot then be made mandatory and if the Agent does not complete the field in this way (easily forgotten while on the phone to the customer) then the issue does not appear on the customer portal resulting in another phone call from the customer.

I agree with Mike Pinch in that this is a fundamental requirement. How do Atlassian envisage Agents using the Create Issue in Service Desk without the one most important Service Desk specific field? It would be like Bug reports not allowing 'Fix Version'.

As I write this 105 others have voted for this yet Atlassian have not given any reason as to why the field is blocked from being added to the Create Screen.

How on earth do you let a ticket like this sit open for 2 years? This bug breaks the basic functionality of your entire platform! The core basic functionality of the entire platform is broken because of this - we would need to architect a hack just to make the product usable.

Hi there,

I'm looking forward to this change.

Because, on the default screen I can edit type request but I cant change the custom fields some like "Cliente" and "Sistema", But on screen edit can edit the custom fields and "cliente" and "sistema" but cant edit the type request.

It is very labor intensive using the tool. Very annoying that.
The user has to make a 10 clicks more. Too bad.

Thank you!

Hi there,

I've been in contact with JIRA's support over this issue and they suggested that I leave some feedback on this ticket for your dev team. We are having problems with use case #2, and assume the same would occur for use case #3.

When an agent creates a ticket on behalf of a customer on JIRA, the request type comes up as 'no match' as there is no custom field for this in issue creation. We cannot manually change the request type on the issue, unless we use Firefox. Chrome throws back an error: "The JIRA server could not be contacted. This may be a temporary glitch or the server may be down".

This is problematic for us, as if an agent forgets to change browser and manually set the request type, the customer cannot get notifications on, see or comment on the request. Our agents should not have to go through the portal to avoid this.

There should be a way to automatically set the request type when creating a ticket in JIRA depending on the issue type, as all our issues have one corresponding request type.

Hi,

We are on Jira 6.4 and JSD 2.5.8.
I have tried to make Customer Request Type visible without success... it is always Locked and when i use Add field option i got the message: The field was added successfully, but you do not have edit permissions.
I have added this field on Screen schema and Field configuration schema.
I'm admin with service desk agents rights.

We have to upgrade our Jira to be able to make it visible or... ?

Thank you

I have added the fields to the screens I need, in hopes that when this is working it will magically appear! (Like the request participants field, which is now working, YAY!)

Finally I found this thread! Basically I have a problem to change the request type as and SD Agent. This is a drawback and irritates, as it requires the issues are beeing created in customer portal with the intended request type, as that cannot be corrected afterwards by an agent. I second Vincent's answers/usecases.

Thanks
Krister

@Vincent Wong [Atlassian]

I appreciate your help with the issue but I am a little confused with the statement exploring a few solutions. Wouldn't the solution be to make it visible on the create and edit screen?

Thanks

Thank you for all the feedback provided! We are currently exploring a few solutions for this based on the use case from the feedback. Once we have something I will definitely share it with you all!

Thanks again for the responses

– JIRA Service Desk

Primary use case is #2

This is our issue also:

This is a big problem for us. We have lots of Agents using JIRA SD and, although we can tell them to always create Service Desk issues through the portal, it is inevitable that some will use the create button (especially as a lot of them are used to using the non-Service Desk JIRA). This means that, unless the Customer Request Type is populated immediately after creation of the issue (probably not likely if they have already forgotten to create the issue via the portal), then the Customer won't be able to see the issue on their portal and, more importantly, the customer isn't notified of the creation and/or any updates on the ticket.

And with the latest version of Service Desk it is even harder to get the Agents to use the portal. In previous version with Service Desk drop down there was an option to Create Service Desk Request. That is no longer available and the Agent needs to go into Customer Channels and Visit Portal to create a ticket. This is not intuitive at all. The agents are working in JIRA and should be able to create the ticket easily from within JIra.

Tim,
Can you clarify on how you are going automation for linked issues? We can take it offline so as not to derail this thread. My email is jtillett at franklinamerican dot com

Our use case would be 2 & 3.

But I think it's important to note that only a JSD agent can link other issues to the ticket being created - the customer cannot do this.

Think if a customer calls and is having trouble with their service, the JSD agent could say "This is related to an Outage that we're aware of and current working to resolve. Would you like me to raise a support ticket on your behalf? That way as soon as the Outage is resolved you will be notified."

The JSD agent could then forget about this ticket, as it would automatically notify the customer when the Outage issue is resolved (via the "is caused by" link and automation).

I agree with the others, this is a bug...

Attachment here!!

Pls see the error message

^^ this and what Joe said
Why treat this as a 'special' field? Just let us show it where we want!

To be honest this is simply a bug. You can select it on your Screen section and it just won't show up. The Where is my field? will show you it should be visible too. Now there are commercial plugins to solve this bug. How are they even approved marketplace listings?

How is 1 even possible? Non-agents are unable to create issue in a JSD project currently via the standard interface - this has to be done via the portal where this issue does not exist.

1 Yes, we integrate our "power" users into our agile development projects, then when we transfer them to support after the agile project is complete. Since they are proficient at the Jira interface, these users are unhappy with the less versatile portal user experience. These users would prefer to use the Jira interface to create and comment issues. These issues often need to be tracked/seen by regular portal users as well.
2 Yes, we take phone calls and create tickets on the fly for Level 1 services. These are usually created and closed in a single session.
3 Yes, we will identify preventative maintenance in operations support, but we usually want the portal user to have access to see the issue and comments, especially if there is need of downtime to resolve.

1) Yes - This step is consistently forgotten by every member of the team. It's just not convenient that it's missing on the "create issue" screen.
2) Yes - Ditto
3) Yes - My team follows the ITIL framework, so our changes/problems live in the exact same place our user-facing issues do.

2. Yes
3. Yes

2. Yes
3. Yes

#2
#3 a bit, but I'm less concerned about this because it's the notifications to outside customers I'm really concerned with.

After we disabled agents ability to create tickets in JIRA, thus forcing them to create through portal, we have worked around the specified use cases 1 to 3.

4. We have a generic request type called "Other / Unknown Request" for users that are unsure on what type of request they have. When agent then categorize this issue through workflow transition, it would be nice for the agent to be able to edit issue type and request type in one go instead of having to edit outside of workflow. This would also enable use to lock down the ability to edit said fields without through workflow.

1. Yes but not very frequent.
2. Yes.
4. We utilize mail handlers for creating issues from especific email addresses.

1. Yes, not very frequent.
2. Yes, this happens very frequently. I've worked around this by making an automation that automatically sets customer request type if its empty, but this is a poor solution when you have more then one customer request type.
3. Does not happen often.
4.Other use case: One of our Service Desks wanted to use several issue types, but not alot of customer request types. I couldnt find any way around this so I had to create one corresponding customer request type for each issue type to make them viewable in the helpcenter. I should be able to map several issue types to one customer request type and also not be forced to create a bunch of different customer request types.

2. Yes
3. Yes

2. Yes
3. Yes

It could happen many at times that the JSD would need to raise a request. The good thing is it allows for the ticket to be raised, but doenst give a customer request type (default / options to choose from?)

1. Yes
2. Yes
3. Yes
4. JSD email feature only allows for one email = one issue type. We then have to utilize traditional mail handlers for creating other issue types from other email addresses. These do not get a request type and customers do not get JSD notifications
4. We use a third party CRM that creates JSD issues using the CreateIssueDetails!init.jspa? URL with field variables specified in the URL - generated from Cisco Finesse screen pop workflows. These tickets do not get a request type and customers do not get JSD notifications.

2. Yes.
4. It should really also appear on the "Move issue" page when moving a ticket into a service desk project, ideally as a mandatory field for service desk projects, just like it is possible to do with any other custom field (a common issue with us is moving tickets between 2 of our service desks and the tickets losing their request type).

Hi Vincent,

Besides case 2, this is our use case 4:

Agents click on the JIRA 'Create' button and forget to set a request type.

Adding Customer Request Type to the Create screen would let:

1. JIRA Admins set a default value, if they wish to.
2. avoid generation of extra notifications.
3. reduce the number of times a customer says 'I cannot see the ticket'.

Number 2 is the important one for us, too.

#2 as well, agents shouldn't have to do this via the customer portal perse.

Number 2 is the primary one for us. Number 3 is a subset of that really.

Service Desk Agents need to be able to log issues in the SD project through the conventional interface and set the customer request type so that updates etc are received.

As a work around I have set a Post Function on create which runs a custom script to set the customer request type.

Hi all,

Thank you for taking your time out and giving feedback on this ticket. I am just wondering what use cases do you guys fall into with this feature request:

1. The user is a JIRA user (not a JSD agent) but would like to raise request for a JSD project from the JIRA side
2. The user is a JSD agent and is raising the ticket on behalf of a customer in the JSD project
3. The user is a JSD agent is is raising a ticket for themselves.
4. Other use case: please specific

I would love to hear about what use cases you guys have and see what solution we can do to best suit your needs.

Cheers,
Vincent - JSD Product Manager

I'm really surprised this is an issue. I have to remember to go back and add the request type once I've completed creating the ticket. Inevitably I forget now and again and customers do not receive any communication regarding the issue. A big dissatisfier when that happens.

Creating an issue on behalf of a customer is one of the basic use-cases, as often it's necessary to provide multiple options for contacting support. I cannot understand that this is not supported directly by setting the issue type and done. Yes, it's JIRA behind this, but I bought Service Desk and expect that it covers the basic use-cases.
Having Request Type visible to me is just a workaround, but better than nothing. So if you cannot link setting RequestType automatically, at least make Request Type visible - SOON!
We keep losing customer feedback because issues without RequestType do not generate notifications - it's SERIOUS!

We really need this

They don't work on ANY version for me. Other fields stored in the same table, do work. But not Customer Request Type.

Ryan, Could you please clarify on which version this issue is resolved.

Which version do you think the above is correct for Ryan? Certainly not for v6.3.10.

Why is this still a problem? Customer Request Types exist in the database exactly like all the other custom fields do - and THEY can be added to screens. This is really annoying because my users prefer to send emails for support, and my technicians keep forgetting to set the request types...

Help needed - Not sure if my issue is completely related to the ticket raised.I dont need to edit the field at all - BUT - I am not able to see the customer request type details on my issue filters. I have configured it for the customer portal. When people create issues from customer portal or from the service desk, the field details appear sometimes and sometimes they dont. Any suggestions??

This is absolutely NOT a suggestion, it's but a BUG. Customer Request Type is a field and I can't think of any reason why it should not be in a screen.

+1

This would be a huge help for us as well. It's a lot faster to create issues through that screen as a service desk agent.

We definitely need this as well.

We have approximately 27 different service desks and often create tickets through Jira. If we forget to set the Service Desk Request Type, which is easy to do, then our clients miss out on critical notifications.

This one has my vote!

We need this as well. We currently integrate JIRA core with our custom CRM and we create issues using URL variables. We need to be able to define this variable, as well as raise issues on behalf of new customers via JIRA core URL.

In plugin Extension for JSD there is customfield called "Extension for JSD - Request Type" which allows agents to edit Customer Request Type and also choose it on Creation Screen. If you use also "Actions for JSD" there is possibility to add this customfield to transition screen for customers and customers can edit it in Customer Service Portal.

Any time frame on this issue?

We need this too.

Also we need to set the request participants in the create screen in JIRA, not only via editing the issue.

This is a big problem for us. We have lots of Agents using JIRA SD and, although we can tell them to always create Service Desk issues through the portal, it is inevitable that some will use the create button (especially as a lot of them are used to using the non-Service Desk JIRA). This means that, unless the Customer Request Type is populated immediately after creation of the issue (probably not likely if they have already forgotten to create the issue via the portal), then the Customer won't be able to see the issue on their portal and, more importantly, the customer isn't notified of the creation and/or any updates on the ticket.
The same thing happens if the Issue Type is changed. The Customer Request Type then changes to "No Match" and the Customer won't be able to view the issue or be notified of any changes (but the Agent who is changing or commenting on the issue will assume that the Customer IS being notified, so could be waiting for a reply to something that hasn't been sent).
I can make the Customer Request Type a mandatory field on each transition, but we need a way of displaying the Customer Request Type field on the transition screen, else the Agent will be informed it is mandatory, then have to go back to the "View" screen to edit the field via inline edit, which isn't ideal.

This should be possible, otherwise if creating a request for a customer, the agent needs to go through the customer portal instead of creating the request in JIRA right away.

For me this is not a suggestion. Its more a Bug that the field can't be edited in edit and create-Screens.

Nice initiative, but really, this should've been standard in Jira Service Desk without plugin.

We coma across this issue quite a lot by our customers, so we have build a custom add-on to solve this issue. We took the time to make it stable and compatible with more recent versions of JIRA and Service Desk and it's now also available via the MarketPlace: https://marketplace.atlassian.com/1213615

Hope it can help you guys too!

This is a very important feature in a scenario where agents also operate a call centre and report requests on behalf of the customers (phone call). Without this feature, the agent has to report the request through the service desk portal, which has a less efficient user interface and is not the "normal" working environment. Alternatively, the agent may create a JIRA issue directly, and tag it with customer request type afterwards, but then the customer won't get the correct notification email.

Getting this would add a lot of value to us, especially if the customer request type is prefilled when there is a one-to-one relationship between issue type and customer request type.

For those issue types that match the Service Desk type, it makes sense that the Service Desk type automatically match the issue type on creation. This is the same, but reverse, of the issue type being set based on the Service Desk type chosen in the portal.

It seems like the functionality was changed to have that field editable from the View Issue screen within Service Desk (under the 'Service Desk Request' section), but it's a lot more convenient to have it as a standard JIRA field so it can be modified right on the Create Issue (or Edit, etc.) Screen the way it was in v2.1.

We're seeing the same issue when adding the Customer Request Type on any custom screen. No matter the screen it seems the field doesn't show up for editing. (We're using Jira Cloud if that helps)

cc: jhuynh