• We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      Updated 16 May

      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

      Updated 6 May

      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

      Since Service Desk 2.1 we can edit the Customer Request type, but the field is not visible on the Create or Edit screen. I added the field and when I go to Configure Fields, I can check the field. Something is happening (some white space is added where the field should be), but the field is not visible.
      I know we can raise a request for a customer throught the portal in his name, but, it should be visible on those screens.

      Workaround

      Automatically set Customer Request Type When Issue is Created via JIRA.

        1. CRT.PNG
          CRT.PNG
          59 kB
        2. Customer Request Type.png
          Customer Request Type.png
          155 kB
        3. Customer Request Type not on Create Issue screen.mov
          2.13 MB
        4. image-2016-07-22-09-13-27-459.png
          image-2016-07-22-09-13-27-459.png
          13 kB
        5. Reuest Type - Service Desk.png
          Reuest Type - Service Desk.png
          138 kB

          Form Name

            [JSDSERVER-1211] Customer Request Type not visible on edit and create screens

            It is fixed in Server version but Cloud still does not work

            https://jira.atlassian.com/browse/JSDCLOUD-1211

            Lucas Modzelewski [Lumo] added a comment - - edited It is fixed in Server version but Cloud still does not work https://jira.atlassian.com/browse/JSDCLOUD-1211

            Hey,

            My use-case that is affected by this is when I need to move a JSD issue from one desk to another. This happens quite a lot that users are creating the issue in the wrong desk and when the agent "escalates" the issue to the correct desk the Customer Request Type is cleared and the issue unavailable to the user.

            It would be great if at least the Move operation could provide me with an option to set the new Customer Request Type.

            Cheers,

            // Svante

            Svante Gustafsson Björkegren added a comment - Hey, My use-case that is affected by this is when I need to move a JSD issue from one desk to another. This happens quite a lot that users are creating the issue in the wrong desk and when the agent "escalates" the issue to the correct desk the Customer Request Type is cleared and the issue unavailable to the user. It would be great if at least the Move operation could provide me with an option to set the new Customer Request Type. Cheers, // Svante

            Why is this not classified as a bug in JIRA Service Desk? It is clearly functioning incorrectly.

            1. The Customer Request Type field** is available to be added on the create Screen.
            2. The Customer Request Type field can be added to the create Screen using standard JIRA Screen editing functionality.
            3. JIRA does not provide a warning to the JIRA admin that it will not be shown on the create Screen.

            So whilst the JIRA screen configuration is correct. This is completely ignored and the field is simply not shown at all - without reason. Dude, that's a bug.

            Even using the JIRA REST API, you have to perform two requests to submit an issue correctly and set the Customer Request Type field. First request to create the issue, second request to set the Customer Request Type. Bizarre.

            Justin Freeman added a comment - Why is this not classified as a bug in JIRA Service Desk ? It is clearly functioning incorrectly. The  Customer Request Type field ** is available to be added on the create  Screen. The Customer Request Type field can be added to the create Screen using standard JIRA Screen editing functionality. JIRA does not provide a warning to the JIRA admin that it will not be shown on the create Screen. So whilst the JIRA screen configuration is correct. This is completely ignored and the field is simply not shown at all - without reason. Dude, that's a bug. Even using the JIRA REST API, you have to perform two requests to submit an issue correctly and set the Customer Request Type field. First request to create the issue, second request to set the Customer Request Type. Bizarre.

            Also need this feature, it is quite common for a service desk agent to open an issue on behalf of the customer, especially if the Internet is not working or the PC is not working etc.  Any news on when this will be added? 

            Karol Jochelson added a comment - Also need this feature, it is quite common for a service desk agent to open an issue on behalf of the customer, especially if the Internet is not working or the PC is not working etc.  Any news on when this will be added? 

            If the request type is not set, customers cannot see the issue at all.  So, they don't get any updates, and they won't be able to give a rating for service.

            You can try it yourself..make a service desk ticket without a request type, and try to access it via the customer portal link - https://yoursite.jira.com/servicedesk/customer/portal/#/*issue number*

            Jimmy Liang added a comment - If the request type is not set, customers cannot see the issue at all.  So, they don't get any updates, and they won't be able to give a rating for service. You can try it yourself..make a service desk ticket without a request type, and try to access it via the customer portal link - https://yoursite.jira.com/servicedesk/customer/portal/#/*issue  number*

            Mark Huey added a comment -

            Yes this was the case for us. We set up a generic request type for our portal that we mapped to a generic issue type in Jira that we could use for our issue creation workflow. So basically, all issues created by agents in the Service Desk project will have to be the generic request type/Issue type called "Service Request" when they are created.

            Then, from there agents progress the issue by transitioning to a different request type each with it's own workflow. However since the issue was created with a valid Request Type at first, even after we change it to an issue type that is not mapped to a Request type, the "Customer Request Type" stays what it originally was. So the Request Type field in the "Service Desk Request" box on the right will have "No Match" but the issue will still be visible on the Customer Portal. 

            Mark Huey added a comment - Yes this was the case for us. We set up a generic request type for our portal that we mapped to a generic issue type in Jira that we could use for our issue creation workflow. So basically, all issues created by agents in the Service Desk project will have to be the generic request type/Issue type called "Service Request" when they are created. Then, from there agents progress the issue by transitioning to a different request type each with it's own workflow. However since the issue was created with a valid Request Type at first, even after we change it to an issue type that is not mapped to a Request type, the "Customer Request Type" stays what it originally was. So the Request Type field in the "Service Desk Request" box on the right will have "No Match" but the issue will still be visible on the Customer Portal. 

            SHOLLON added a comment -

            We have seen an issue where if the request type isn't updated in the JIRA ticket that the notifications don't go out to customers. Is anyone else seeing this issue? 

            SHOLLON added a comment - We have seen an issue where if the request type isn't updated in the JIRA ticket that the notifications don't go out to customers. Is anyone else seeing this issue? 

            We have the same need. We've tried several work around solutions, but they don't ever work correctly because we have highly specialized mappings of IssueTypes -> Request Types. Agent take calls, IM, chat, etc. We've tried to use automation, but due to the above that doesn't work. Ultimately, we just need to be able to set the request type at the creation screen. Please fix!

            Michael McFarland added a comment - We have the same need. We've tried several work around solutions, but they don't ever work correctly because we have highly specialized mappings of IssueTypes -> Request Types. Agent take calls, IM, chat, etc. We've tried to use automation, but due to the above that doesn't work. Ultimately, we just need to be able to set the request type at the creation screen. Please fix!

            We also use the create screen when agents create the ticket - for request received through phone call, IM chat, etc. We need to be able to set:
             - request type
             - organisation
             - participants

             

            Rein Remmel added a comment - We also use the create screen when agents create the ticket - for request received through phone call, IM chat, etc. We need to be able to set:  - request type  - organisation  - participants  

            quite unfortunate for us, that this is not working... please fix

            Pasha Shabalin added a comment - quite unfortunate for us, that this is not working... please fix

            Mark Huey added a comment - - edited

            Case 2

             

            I would think that it would be pretty common in many cases for service desk agents to enter tickets on behalf of their customers who call in. 

            Mark Huey added a comment - - edited Case 2   I would think that it would be pretty common in many cases for service desk agents to enter tickets on behalf of their customers who call in. 

            My use case is as such:

            We are utilizing a service desk project as an asset/inventory tracking system.  We have a few issue types configured (Asset, Consumable, Purchase Order). I've set up numerous request types in the portal for each type of asset (desktop computer, iPad, Chromebook, Projector, etc) that all use the issue type of 'asset', of which I've presented the relevant custom fields. This works very well for provisioning new assets.  

            However, we have an extensive inventory of devices strewn all over our organization that may or may not exist in any database or spreadsheet.  I've found the only sure-fire way to provision these devices is to go around room-by-room, building-by-building, and hand enter every device.  While the customer portal is a great way to enter very basic details about an asset, I've found that a screen that groups fields into different tabs based on their function (location, network info, etc) is more efficient, but if I go that route by using the 'Create' button, I don't get to select the customer request type to actually identify the type of asset.

            My only workaround at this point is to create a new custom field that is hidden in the portal with a default value setting the type, but it seems odd to have to duplicate data.

            While I could create a spreadsheet with all of the asset details and import into the project; this is not ideal, as I also fire off a webhook when an asset is created that prints a scan-able asset label linking back to the issue.

            Tyler Knight added a comment - My use case is as such: We are utilizing a service desk project as an asset/inventory tracking system.  We have a few issue types configured (Asset, Consumable, Purchase Order). I've set up numerous request types in the portal for each type of asset (desktop computer, iPad, Chromebook, Projector, etc) that all use the issue type of 'asset', of which I've presented the relevant custom fields. This works very well for provisioning new assets.   However, we have an extensive inventory of devices strewn all over our organization that may or may not exist in any database or spreadsheet.  I've found the only sure-fire way to provision these devices is to go around room-by-room, building-by-building, and hand enter every device.  While the customer portal is a great way to enter very basic details about an asset, I've found that a screen that groups fields into different tabs based on their function (location, network info, etc) is more efficient, but if I go that route by using the 'Create' button, I don't get to select the customer request type to actually identify the type of asset. My only workaround at this point is to create a new custom field that is hidden in the portal with a default value setting the type, but it seems odd to have to duplicate data. While I could create a spreadsheet with all of the asset details and import into the project; this is not ideal, as I also fire off a webhook when an asset is created that prints a scan-able asset label linking back to the issue.

            Use Case #2 for us

            Susan Hauth [Jira Queen] added a comment - Use Case #2 for us

            I've nearly completed my build and I'm thinking this is going to be a hard sell to our Service Desk. They're currently using WHD and may decide to stay with that system. Editing request types are pretty vital since so many end users just choose the first request type on the list. Any idea when this might be viewable in screens?

            Kristin Bitler (mty.k12) added a comment - I've nearly completed my build and I'm thinking this is going to be a hard sell to our Service Desk. They're currently using WHD and may decide to stay with that system. Editing request types are pretty vital since so many end users just choose the first request type on the list. Any idea when this might be viewable in screens?

            This is a pretty important feature in the automation of workflows and I was actually shocked that the cloud version can't support this.  It might make it so we have to move this in-house

            Derek Picard added a comment - This is a pretty important feature in the automation of workflows and I was actually shocked that the cloud version can't support this.  It might make it so we have to move this in-house

            Oliviu Nita added a comment - - edited

            Hi,

            @Wes Mason and @Cole, noob question: how the JQL looks like ? It was very easy to find the Automation, i'm very close to do it BUT when i want to chose Customer request type a message told me to switch on Advanced..., when i do that i have to input an JQL sentence.
            So my Automation rule sound like this:
            WHEN:
            issue created
            IF:
            Status: All
            Reporter: All
            Priority: All
            Customer Request Type: is All by default => with the down arrow to chose between options, when i click on the arrow i see the switch to advanced menu, when i switch i have to manually input the JQL... and i don't know what i have to write
            And this rule will be active only for our JSD because for the Agile projects this Field is missing (even if my team mates have asked for...)

            Thank you all in advance and have a sunny day

            LE: i have not activated yet the rule, i wait yours answers, i want ONLY for the empty Customer request type to edit in *General Request

            LE 2: It was in front of my EYES !!! DOOOH )
            @Wes a HUGE thank's from me and my Helpdesk Team
            I still have another question:
            We use 4 request types:
            Demande Informatique
            Panne Informatique
            Doublon
            Lotus

            I have added the rule:
            WHEN Issue created
            IF Issue Matches Status: All Reporter: All Priority: All Customer Request Type is EMPTY
            THEN Edit request type 2.1 Declaration d'un incident informatique

            Now all the issues created in backoffice are Panne Informatique (doesn't matter if i chose Lotus by eg) => my resp are agreed but have asked me if it is possible to have the right input when we chose other request type (to have Other Lotus as Customer Request Type when i create a Lotus issue type by eg)
            The test i made: added ELSE IF for Lotus and Doublon and the system put me all the new created issues as Doublons as Customer Request Type i have fast deleted the 2 ELSE IF and we will use for all new created issues the Panne Informatique Customer Request Type

            The question is: can i use different trigerrs for different Customer request Type ?

            Thank you again

            LE 3: ALL is perfect i have take it a deep breathe and i have modified the ELSE IF and... BINGO we have the Customer Request Type auto added for all our 4 Request Types YUUUHUUUUU )

            Anyway Wes you are the Hero of the day, this will HAVE to be added as a stable and simple FIX for this semi-bug

            Have a sunny beautifull day

            Oliviu Nita added a comment - - edited Hi, @Wes Mason and @Cole, noob question: how the JQL looks like ? It was very easy to find the Automation, i'm very close to do it BUT when i want to chose Customer request type a message told me to switch on Advanced..., when i do that i have to input an JQL sentence. So my Automation rule sound like this: WHEN: issue created IF: Status: All Reporter: All Priority: All Customer Request Type: is All by default => with the down arrow to chose between options, when i click on the arrow i see the switch to advanced menu, when i switch i have to manually input the JQL... and i don't know what i have to write And this rule will be active only for our JSD because for the Agile projects this Field is missing (even if my team mates have asked for...) Thank you all in advance and have a sunny day LE: i have not activated yet the rule, i wait yours answers, i want ONLY for the empty Customer request type to edit in *General Request LE 2: It was in front of my EYES !!! DOOOH ) @Wes a HUGE thank's from me and my Helpdesk Team I still have another question: We use 4 request types: Demande Informatique Panne Informatique Doublon Lotus I have added the rule: WHEN Issue created IF Issue Matches Status: All Reporter: All Priority: All Customer Request Type is EMPTY THEN Edit request type 2.1 Declaration d'un incident informatique Now all the issues created in backoffice are Panne Informatique (doesn't matter if i chose Lotus by eg) => my resp are agreed but have asked me if it is possible to have the right input when we chose other request type (to have Other Lotus as Customer Request Type when i create a Lotus issue type by eg) The test i made: added ELSE IF for Lotus and Doublon and the system put me all the new created issues as Doublons as Customer Request Type i have fast deleted the 2 ELSE IF and we will use for all new created issues the Panne Informatique Customer Request Type The question is: can i use different trigerrs for different Customer request Type ? Thank you again LE 3: ALL is perfect i have take it a deep breathe and i have modified the ELSE IF and... BINGO we have the Customer Request Type auto added for all our 4 Request Types YUUUHUUUUU ) Anyway Wes you are the Hero of the day, this will HAVE to be added as a stable and simple FIX for this semi-bug Have a sunny beautifull day

            Cole added a comment -

            @Wes Mason Thank you so much! Did not realize I could do all of that in there!

            Cole added a comment - @Wes Mason Thank you so much! Did not realize I could do all of that in there!

            Cole –

            1. Project Settings > Automation
            2. Create New Automation
            3. When "Issue Create"
              1. If Issue Matches "Customer Request Type" is EMPTY and issuetype in (Task)
                1. *Then Edit Request Type: *General Request

            You can create as many If -> then statements as you want to take care of different request types based on the Issue Matches JQL statement.

            Wes Mason [he / him / his] added a comment - Cole – Project Settings > Automation Create New Automation When "Issue Create" If Issue Matches "Customer Request Type" is EMPTY and issuetype in (Task) *Then Edit Request Type: *General Request You can create as many If -> then statements as you want to take care of different request types based on the Issue Matches JQL statement.

            Cole added a comment -

            @Wes Manson What type of post function did you use to make it automatically set the customer request type? I cannot seem to get it to work.

            Cole added a comment - @Wes Manson What type of post function did you use to make it automatically set the customer request type? I cannot seem to get it to work.

            hr hrm added a comment -

            Lack of this field, Service Desk type, is so frustrating! If you do not add this fild Atlassian I will buy another product.
            I think this is not oversight - you do it deliberately for some reason.
            Another annoying thing is that when I create linked issue I cannot add reporter, I cannot choose Service Desk type.
            Change it!!!

            hr hrm added a comment - Lack of this field, Service Desk type, is so frustrating! If you do not add this fild Atlassian I will buy another product. I think this is not oversight - you do it deliberately for some reason. Another annoying thing is that when I create linked issue I cannot add reporter, I cannot choose Service Desk type. Change it!!!

            Sudha added a comment -

            @Wes Mason! Exactly, That's what I did too to manage - Just use the workflow with email triggers. And Like you said, it doesn't help at all as the SD gets million of emails and this will get lost in that ocean. We need that field in the CREATE / EDIT Screen and we need it to be mandatory for SD to work on the ticket.

            Sudha added a comment - @Wes Mason! Exactly, That's what I did too to manage - Just use the workflow with email triggers. And Like you said, it doesn't help at all as the SD gets million of emails and this will get lost in that ocean. We need that field in the CREATE / EDIT Screen and we need it to be mandatory for SD to work on the ticket.

            sudha.bhat-- I've created a custom field with the type "Message Custom Field" and made it show up on the "Create Issue" screen through JIRA Software / Core that reminds users to submit requests through the support portal flow. I've also created an automation in Service Desk for "IF Customer Request Type is EMPTY WHEN Issue is Created THEN Set Customer Request Type TO "it-support/General Request".

             

            It's not perfect, but it means that all tickets will show up in the Customer Support Portal.

            Wes Mason [he / him / his] added a comment - sudha.bhat -- I've created a custom field with the type "Message Custom Field" and made it show up on the "Create Issue" screen through JIRA Software / Core that reminds users to submit requests through the support portal flow. I've also created an automation in Service Desk for "IF Customer Request Type is EMPTY WHEN Issue is Created THEN Set Customer Request Type TO "it-support/General Request".   It's not perfect, but it means that all tickets will show up in the Customer Support Portal.

            Sudha added a comment -

            Just if this helps ; Currently I have just requested my SD team to change the Customer Request Type once the ticket is created to make it available to the customer portal to see the tickets. Usually this shall be available for edit at all times as per the permissions provided and the customer request type shall be available in the drop down. This is an alternate solution we are using, but !! BEWARE most of the times the team members do not remember to change it!! Its still a challenge

            Sudha added a comment - Just if this helps ; Currently I have just requested my SD team to change the Customer Request Type once the ticket is created to make it available to the customer portal to see the tickets. Usually this shall be available for edit at all times as per the permissions provided and the customer request type shall be available in the drop down. This is an alternate solution we are using, but !! BEWARE most of the times the team members do not remember to change it!! Its still a challenge

            But if a customer can select a request type, I don't see why an agent should be any different. Certainly shouldn't have less access than a customer...

            Lyden Yardley added a comment - But if a customer can select a request type, I don't see why an agent should be any different. Certainly shouldn't have less access than a customer...

            Ignacio Pulgar added a comment - - edited

            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)

            Ignacio Pulgar added a comment - - edited 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?

            Lyden Yardley added a comment - 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.

            Gordon Camley added a comment - 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.

            Mike Pinch added a comment -

            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.

            Mike Pinch added a comment - 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!

            Julierme Martins added a comment - 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!

            hannah_white1289362472 added a comment -

            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.

            hannah_white1289362472 added a comment - 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

            Oliviu Nita added a comment - 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!)

            Donna Menhennett added a comment - 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!)

            Krister Persson added a comment - - edited

            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

            Krister Persson added a comment - - edited 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

            Adam Morrison added a comment - @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

            vwong added a comment - - edited

            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

            vwong added a comment - - edited 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.

            Jenifer Kuntz added a comment - 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

            Jeff Tillett added a comment - 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

            Tim Clydesdale added a comment - - edited

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

            Tim Clydesdale added a comment - - edited 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...

            Sudha added a comment -


            Attachment here!!

            Sudha added a comment - Attachment here!!

            Sudha added a comment - - edited

            Pls see the error message

            Sudha added a comment - - edited 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!

            Jan Cornelissen added a comment - ^^ 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?

            Patrick van der Rijst added a comment - 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?

            Joe Smith added a comment -

            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.

            Joe Smith added a comment - 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.

            Ken Anderson added a comment - - edited

            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.

            Ken Anderson added a comment - - edited 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.

            Kevin Leaverton added a comment - 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

            Marcel Wirtz added a comment - 2. Yes 3. Yes

            2. Yes
            3. Yes

            Oliviu Nita added a comment - 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.

            Rachel Robillard added a comment - #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.

            Alf Karlsen added a comment - 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.

            João Samuel do Prado added a comment - 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.

            Stian Bentsen Sveen added a comment - 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

            Adam Morrison added a comment - 2. Yes 3. Yes

              mmcmahon Matthew McMahon (Inactive)
              9cb130dade9f Jan Cornelissen
              Votes:
              234 Vote for this issue
              Watchers:
              204 Start watching this issue

                Created:
                Updated:
                Resolved: