• 18
    • 13
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

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

      We would like to user the service desk to allow customers to create bugs and feature requests through a simple interface on an existing Jira project.
      There would then be 'agents' that would curate these issues and then hand them to the development team if confirmed.
      This all works nicely and as expected. The only problem is that the developers are not 'agents' but 'collaborators', and Service Desk therefore prevents them from editing / transitioning the issues.

      It means we cannot streamline our support with our development process. We would need separate support and development projects and duplicate/link the issues between them.

      Would it not be possible to remove this restriction? The collaborators should be able to do whatever their given permissions are. They don't need access to the full service desk view. We are still paying for their user license anyway.
      Agent licenses will still be needed (and purchased) to use the full Service Desk portal features. Otherwise it is a convoluted user experience.

      Atlassian response:

      Service Management best practices would typically see the engagement of software engineering as a separate process. Combining the two could be a potential source of inefficiency. e.g. Assigning support tickets to engineers may disrupt queues, lead to incorrect SLA calculations etc.

      Usually, agents are those communicating with customers through the tickets and the portal. When engineers work on a ticket they will change its description, add steps to reproduce, effort estimations, sprints etc - which are all internal information that the agent may not want to share with the customer. 

      However, we recognise that the need expressed in this ticket is of high priority and importance. We should have a streamlined workflow between JSM and JSW, allowing agents to easily get engineers' assistance. The solution can include a few elements:

      • An efficient workflow of an agent requesting engineering assistance
        This can currently be achieved through automation (see example). However, to get some additional information the engineer will need to go to the original JSM ticket (attachments, comments). We will evaluate opportunities for improving this capability.
      • Provide customers update about the JSW ticket status
        Sometimes, the agent wants the customers to know if the JSW ticket is in progress, on hold etc.
        1. This can be achieved through apps such as Extension for JSM. (see also automation example).
        2. There is an open JAC request for this feature View linked issues in the customer portal.
            The relevant team updated that they will consider it in their next roadmap discussions

      Note: See similar issue "Jira Service Desk should not restrict Project actions" with 123 votes

      Thanks,

      JSM Team.

            [JSDCLOUD-931] Allow collaborators to modify issues dependent on their permissions

            Hi,

            As explained in one of my support ticket, we have some of our customers working with us on the support tickets, and they have a Jira Software License.

            They don't understand why they can't do what they can do through the Portal, in JIRA.

            It doesn't make sense from a user perspective that a user who has access to Jira must go to the portal to transition, put a public comment or do anything that a classic customer can do.

            Don't take it wrong, our customers don't have Agent roles. They have access to Jira to see the Kanban from the Jira software which contains also JSM tickets.

             

            : idea: when an user has the Jira Service Desk Customer role + a Jira Software license, he should be able able to everything that he can do in the portal, in Jira UI.

             

            I hope it helps. Today, the UX and UI are not harmonized, and our customers get a bit frustrated.

            Florian Royer added a comment - Hi, As explained in one of my support ticket, we have some of our customers working with us on the support tickets, and they have a Jira Software License. They don't understand why they can't do what they can do through the Portal, in JIRA. It doesn't make sense from a user perspective that a user who has access to Jira must go to the portal to transition, put a public comment or do anything that a classic customer can do. Don't take it wrong, our customers don't have Agent roles. They have access to Jira to see the Kanban from the Jira software which contains also JSM tickets.   : idea: when an user has the Jira Service Desk Customer role + a Jira Software license, he should be able able to everything that he can do in the portal, in Jira UI.   I hope it helps. Today, the UX and UI are not harmonized, and our customers get a bit frustrated.

            I need to assign issues in JSM projects to JSW users rarely, once-twice per year, so I don't want them to use JSM licence for whole year if they need it twice.

            It would be nice, if they could edit issues with JSW licence or at least transition and close the issues. Transitioning without JSM licence seems to be something that would not impact the sales of JSM as Customer Portal users can even do transitions in portal. Current workarounds I know are:

            • assignee who doesn't have JSM licence but has JSW licence, can open the request in portal and then resolve it
            • assignee who doesn't have JSM licence but has JSW licence, can execute automation rule, that will close the issue

            They both seem stupid and annoying. I would really like to JSW users being able to transition JSM issues. 

             

            Kerli Loopman added a comment - I need to assign issues in JSM projects to JSW users rarely, once-twice per year, so I don't want them to use JSM licence for whole year if they need it twice. It would be nice, if they could edit issues with JSW licence or at least transition and close the issues. Transitioning without JSM licence seems to be something that would not impact the sales of JSM as Customer Portal users can even do transitions in portal. Current workarounds I know are: assignee who doesn't have JSM licence but has JSW licence, can open the request in portal and then resolve it assignee who doesn't have JSM licence but has JSW licence, can execute automation rule, that will close the issue They both seem stupid and annoying. I would really like to JSW users being able to transition JSM issues.   

             

            Update - 29th September 2022

            Service Management best practices would typically see the engagement of software engineering as a separate process. Combining the two could be a potential source of inefficiency. e.g. Assigning support tickets to engineers may disrupt queues, lead to incorrect SLA calculations etc.

            Usually, agents are those communicating with customers through the tickets and the portal. When engineers work on a ticket they will change its description, add steps to reproduce, effort estimations, sprints etc - which are all internal information that the agent may not want to share with the customer. 

            However, we recognise that the need expressed in this ticket is of high priority and importance. We should have a streamlined workflow between JSM and JSW, allowing agents to easily get engineers' assistance. The solution can include a few elements:

            1. An efficient workflow of an agent requesting engineering assistance
              This can currently be achieved through automation. However, to get some additional information the engineer will need to go to the original JSM ticket (attachments, comments). We will evaluate opportunities for improving this capability.
            1. Provide customers update about the JSW ticket status
              Sometimes, the agent wants the customers to know if the JSW ticket is in progress, on hold etc.
              1. This can be achieved through apps such as Extension for JSM.
              2. There is an open JAC request for this feature View linked issues in the customer portal.
                The relevant team updated that they will consider it in their next roadmap discussions. 

            Thanks,

            JSM Team.

            Yuval Refaeli (Inactive) added a comment -   Update - 29th September 2022 Service Management best practices would typically see the engagement of software engineering as a separate process. Combining the two could be a potential source of inefficiency. e.g. Assigning support tickets to engineers may disrupt queues, lead to incorrect SLA calculations etc. Usually, agents are those communicating with customers through the tickets and the portal. When engineers work on a ticket they will change its description, add steps to reproduce, effort estimations, sprints etc - which are all internal information that the agent may not want to share with the customer.  However, we recognise that the need expressed in this ticket is of high priority and importance. We should have a streamlined workflow between JSM and JSW, allowing agents to easily get engineers' assistance. The solution can include a few elements: An efficient workflow of an agent requesting engineering assistance This can currently be achieved through automation. However, to get some additional information the engineer will need to go to the original JSM ticket (attachments, comments). We will evaluate opportunities for improving this capability. Provide customers update about the JSW ticket status Sometimes, the agent wants the customers to know if the JSW ticket is in progress, on hold etc. This can be achieved through apps such as Extension for JSM. There is an open JAC request for this feature View linked issues in the customer portal . The relevant team updated that they will consider it in their next roadmap discussions.  Thanks,
 JSM Team.

            Moez SAID added a comment -

            +1, please enable this feature!

            Moez SAID added a comment - +1, please enable this feature!

            + 1 Really necessary and not worth paying a complete agent license

            Tilman Boller added a comment - + 1 Really necessary and not worth paying a complete agent license

            Wow, our team really needs to let Jira software users transition JSD issues. We shouldn't all need agent licenses just for this. Please enable this feature!

            Janene Pappas added a comment - Wow, our team really needs to let Jira software users transition JSD issues. We shouldn't all need agent licenses just for this. Please enable this feature!

            John Marsh added a comment - - edited

            +1. Our desired workflow is to create a subtask in a service desk project and allow non-agents to interact with that subtask normally apart from communicating with customers. Currently this is not possible, however, as JSD requires that everyone who interacts with a JSD task in any meaningful way be a licensed agent. It is not practical or desirable to license everyone who could ever be assigned to a service desk subtask to help with an issue. As a workaround, we are creating duplicate issues in separate, internal projects and then creating the subtasks in those. This is just horribly unnecessary. We would like to buy agent licenses for our customer-facing employees only while still allowing internal folks to collaborate. This is the behavior that was suggested during the sales process and this current handicap appears to directly contradict what was described.

            John Marsh added a comment - - edited +1. Our desired workflow is to create a subtask in a service desk project and allow non-agents to interact with that subtask normally apart from communicating with customers. Currently this is not possible, however, as JSD requires that everyone who interacts with a JSD task in any meaningful way be a licensed agent. It is not practical or desirable to license everyone who could ever be assigned to a service desk subtask to help with an issue. As a workaround, we are creating duplicate issues in separate, internal projects and then creating the subtasks in those. This is just horribly unnecessary. We would like to buy agent licenses for our customer-facing employees only while still allowing internal folks to collaborate. This is the behavior that was suggested during the sales process and this current handicap appears to directly contradict what was described.

            We need our collaborators to be able to transition and edit issues but don't want them to be able to make customer facing comments. There is no option for this. Either they are assigned Browse Project permission where they cant add customer comments but also cannot transition / edit issues or add them as a SD Agent meaning they can transition/edit but can also add customer comments. This limits collaborators and really they are not collaborating at all, just commenting.

            Adam Capes added a comment - We need our collaborators to be able to transition and edit issues but don't want them to be able to make customer facing comments. There is no option for this. Either they are assigned Browse Project permission where they cant add customer comments but also cannot transition / edit issues or add them as a SD Agent meaning they can transition/edit but can also add customer comments. This limits collaborators and really they are not collaborating at all, just commenting.

            Same problem. Applied Service Desk to our Internal IT Help desk for just one issue type, but then realized that made all the other issue types that rely on approvers from other departments and steps from the development team unusable. So have had to strip away the one issue type where only IT is required to move the issues around over to Help Desk. Or consider adding in a lot more agents just so they can "approve" a change request.

            Susan Hauth [Jira Queen] added a comment - Same problem. Applied Service Desk to our Internal IT Help desk for just one issue type, but then realized that made all the other issue types that rely on approvers from other departments and steps from the development team unusable. So have had to strip away the one issue type where only IT is required to move the issues around over to Help Desk. Or consider adding in a lot more agents just so they can "approve" a change request.

            Any idea if Atlassian thinks about giving back some permissions to the collaborators?

            Is there an official statement from Atlassian regading that topic?

            Our whole Service Desk has been built around the "old" license scheme - it seems to became useless in an instant after applying the new license. This is really a shame!

            Ubimet support added a comment - Any idea if Atlassian thinks about giving back some permissions to the collaborators? Is there an official statement from Atlassian regading that topic? Our whole Service Desk has been built around the "old" license scheme - it seems to became useless in an instant after applying the new license. This is really a shame!

              96677a1d9b4c Sam Knight
              ddb2c993f62b Jake Bishop
              Votes:
              183 Vote for this issue
              Watchers:
              113 Start watching this issue

                Created:
                Updated: