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

      I think it would be good to be able to hide request types from the customer portal during their development.

      Something as simple as a 'Hide' URL on the Customer Portal -> Request Types page near the 'Edit Form' and 'Delete' area.

      Also, when opening an issue here:
      "Version with id '1.2.5' does not exist."

      Thanks for the consideration!

          Form Name

            [JSDSERVER-465] Ability to hide request types

            Hi everyone,

            JIRA Service Desk 3.2 has been released and this feature is included in version 3.2. Request types can be hidden from the portal now. Details for this version can be found in the release notes: https://confluence.atlassian.com/servicedesk/jira-service-desk-3-2-x-release-notes-830281732.html.

            Cheers,
            Lingbo
            JIRA Service Desk team

            lingbo (Inactive) added a comment - Hi everyone, JIRA Service Desk 3.2 has been released and this feature is included in version 3.2. Request types can be hidden from the portal now. Details for this version can be found in the release notes: https://confluence.atlassian.com/servicedesk/jira-service-desk-3-2-x-release-notes-830281732.html . Cheers, Lingbo JIRA Service Desk team

            Ditto on this feature request.

            In my scenario: I have a few internal Issue Types, for example Problem, Purchase, etc. I don't want these as customer facing Request Types on my Service Portal. Only my Agents should be able to use these. The problem is that if they use Purchase as an Issue Type but want to contact the customer, the customer does not receive any email unless the Issue Type is associated with a Request Type. Workaround is to use a customer facing Issue Type like Service Request which is attached to a Request Type.

            Deleted Account (Inactive) added a comment - Ditto on this feature request. In my scenario: I have a few internal Issue Types, for example Problem, Purchase, etc. I don't want these as customer facing Request Types on my Service Portal. Only my Agents should be able to use these. The problem is that if they use Purchase as an Issue Type but want to contact the customer, the customer does not receive any email unless the Issue Type is associated with a Request Type. Workaround is to use a customer facing Issue Type like Service Request which is attached to a Request Type.

            Ryno Taylor added a comment - - edited

            Agreed, we are rolling Jira in our company now, but some request types are being worked on for future planning. We are unable to implement them now as they require workflows which are not 100% in place yet internally.

            As a result of being able to hide request types, we now need to delete them, which will require reset later. All that work down the drain

            Ryno Taylor added a comment - - edited Agreed, we are rolling Jira in our company now, but some request types are being worked on for future planning. We are unable to implement them now as they require workflows which are not 100% in place yet internally. As a result of being able to hide request types, we now need to delete them, which will require reset later. All that work down the drain

            I'm having the same issue as Bjorn - would like to hide my Email request type from customer portal. Any updates on this issue?

            Kira Taylor added a comment - I'm having the same issue as Bjorn - would like to hide my Email request type from customer portal. Any updates on this issue?

            Maybe instead of hide, it could be group based (which could accomplish the same thing), I'd also like to limit what users can see certain requests.

            Kevin R. Raney added a comment - Maybe instead of hide, it could be group based (which could accomplish the same thing), I'd also like to limit what users can see certain requests.

            FlorianV added a comment -

            I'm having the same problem as Björn mentioned. Would be really nice to hide a request type on the portal.

            FlorianV added a comment - I'm having the same problem as Björn mentioned. Would be really nice to hide a request type on the portal.

            I would really like this feature too. In my example:

            I run an IT department for a healthcare organization. My Request Types are based around "how" the request came to us: i.e. via Email, Phone, or the Web Portal.

            Because of the way JIRA works, when my users go to the Web Portal, they have the option to raise an "Email" request and a "Phone" request. This makes no sense at all to have these here. If I could just hide them, that would be perfect.

            Kevin Leaverton added a comment - I would really like this feature too. In my example: I run an IT department for a healthcare organization. My Request Types are based around "how" the request came to us: i.e. via Email, Phone, or the Web Portal. Because of the way JIRA works, when my users go to the Web Portal, they have the option to raise an "Email" request and a "Phone" request. This makes no sense at all to have these here. If I could just hide them, that would be perfect.

            Pavel added a comment -

            Hi,
            agree with Bjorn, same from our side. Need to have ability to hide form from portal.
            1. Set up of some forms may took a while (specific needs).
            2. Need to go live with form same moment after notification (e.g. email notification to employees from human resources to use new form etc.)

            Pavel added a comment - Hi, agree with Bjorn, same from our side. Need to have ability to hide form from portal. 1. Set up of some forms may took a while (specific needs). 2. Need to go live with form same moment after notification (e.g. email notification to employees from human resources to use new form etc.)

            We are facing another kind of problem where we would like to hide a request type. We have a couple of request types and all of them have a few fields that are mandatory to fill in. In combination with creating issues with incoming emails we have a conflict - for email handling we must have a request type that have no mandatory fields.

            What we want to do is to have a separate request type for email requests which has no mandatory fields. However this request type should not be visible on the customer portal, but only for the agents. This is why we have a need for hiding request types on the customer portal.

            Björn Gullander added a comment - We are facing another kind of problem where we would like to hide a request type. We have a couple of request types and all of them have a few fields that are mandatory to fill in. In combination with creating issues with incoming emails we have a conflict - for email handling we must have a request type that have no mandatory fields. What we want to do is to have a separate request type for email requests which has no mandatory fields. However this request type should not be visible on the customer portal, but only for the agents. This is why we have a need for hiding request types on the customer portal.

            Indeed,

            Right now it is only possible to delete the Request Type. Thus if for any reasons you would like to hide a request type then your only option is to delete and you may lost all your design for a request type. This is especially true for newbie administrator.

            Guy Bonneau added a comment - Indeed, Right now it is only possible to delete the Request Type. Thus if for any reasons you would like to hide a request type then your only option is to delete and you may lost all your design for a request type. This is especially true for newbie administrator.

              Unassigned Unassigned
              b3ef4e65126a RobertH
              Votes:
              25 Vote for this issue
              Watchers:
              25 Start watching this issue

                Created:
                Updated:
                Resolved: