Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-5697

Allow JIRA Service Desk Admins to Decide When Agents should be Treated as Customers

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 22
    • 27
    • 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.

      Summary

      Currently, if an SD Agent plays one of the following roles in an SD ticket:

      1. Reporter - confirmed
      2. Request Participant - confirmed 
      3. Approver - fixed in JSD 4.7.0
      4. Customer Organization member - fixed in JSD 4.7.0  

      THEN he/she is treated as a Customer, not an Agent.

      This doesn't affect the Agent's permissions and abilities to work on the ticket, however causes a few SD specific features not to work as expected by the SD Admins, including SLAs and Automations. For example:

      1. SLA - Comment: For Customers doesn't work when the Agent adds a comment for the customers, because he/she's treated as a customer him/herself (which means the comment is deemed By Customers instead).
      2. Automation - If: User is not a customer doesn't work in a similar way because the Agent is treated as a customer.

      Known Issues

      • When agent comment at issue created by himself , SLA didn't stop as per configured in "Time to Resolution"
      • Automation does not trigger when agent is listed in Request Participant
      • SLA does not pauses when commenting on the issue as participant
      • The condition "Comment:For Customers" in an SLA configuration is not verified when an agent is part of the same organization as the customer
      • The Agent is not considered as a Customer even if he is part of the Organisation. This makes the Automation condition 'User is a Customer' to fail and thus by not executing it.

      Suggestion

      Allow JIRA Admins to decide when an agent should be treated as a customer. This should be configurable at the following levels:

      • System Level - applicable to all projects and issue types
      • Project & Issue Type Level - applicable to specific issue types in specific projects
      • User Preference Level - allow individual users to decide themselves

            [JSDSERVER-5697] Allow JIRA Service Desk Admins to Decide When Agents should be Treated as Customers

            Clemens Kleibusch added a comment -

            I go one step further.
            It is more than annoying to sometimes receive no emails at all instead of duplicate emails. I keep getting reports that no notifications are being sent in individual cases. Unfortunately, all attempts to reproduce this have failed so far.

             

            Clemens Kleibusch added a comment - I go one step further. It is more than annoying to sometimes receive no emails at all instead of duplicate emails. I keep getting reports that no notifications are being sent in individual cases. Unfortunately, all attempts to reproduce this have failed so far.  

            Job Wolters added a comment -

            It is annoying to receive mails twice when you are an agent. As we already receive a lot of mails from Jira it is highly appreciated to make it configurable.

            Job Wolters added a comment - It is annoying to receive mails twice when you are an agent. As we already receive a lot of mails from Jira it is highly appreciated to make it configurable.

            Rabbit Stoddard added a comment -

            Also seeing this same issue; came to report it. This is extremely likely when customers are working through email threads rather than via the portal. 

            Rabbit Stoddard added a comment - Also seeing this same issue; came to report it. This is extremely likely when customers are working through email threads rather than via the portal. 

            Kaushal Patel added a comment -

            Seeing the same issue as reported in JSDSERVER-5238 No Notifications when Assignee = Reporter

            Tested in Jira 8.10.1 Service Desk 4.10.1 - did not work

            Tested in Jira 7.13.5 Service Desk 3.15 - did not work

             

            see ticket GHS-200411

             

            for now, I've got a Scriptrunner (Adaptavist) running to cover the gap

            Kaushal Patel added a comment - Seeing the same issue as reported in JSDSERVER-5238 No Notifications when Assignee = Reporter Tested in Jira 8.10.1 Service Desk 4.10.1 - did not work Tested in Jira 7.13.5 Service Desk 3.15 - did not work   see ticket GHS-200411   for now, I've got a Scriptrunner (Adaptavist) running to cover the gap

            Donna Dowie added a comment -

            I'm facing this challenge too. Our agents don't necessarily want to be request participants, but if our customer creates or updates a ticket via email and cc's an agent, they are automatically added as a request participant. If the agent doesn't notice this before providing a response for the customer, the response is not considered for the customer and doesn't count for SLA comment for customer.

             

            Donna Dowie added a comment - I'm facing this challenge too. Our agents don't necessarily want to be request participants, but if our customer creates or updates a ticket via email and cc's an agent, they are automatically added as a request participant. If the agent doesn't notice this before providing a response for the customer, the response is not considered  for the customer and doesn't count for SLA comment for customer.  

            Bartosz Ornatowski added a comment -

            Hi stefanie.flek,

            Can you please describe how you are using the Request Participants field, and why agents want to be the Request Participants of given issues in your workflow?

            Best Regards,

            Bart

            Bartosz Ornatowski added a comment - Hi stefanie.flek , Can you please describe how you are using the Request Participants field, and why agents want to be the Request Participants of given issues in your workflow? Best Regards, Bart

            Stefanie Flek added a comment -

            As described in the summary: I have the problem, when an agent is also request participant in a ticket and comments for the customer, it does not count for the SLA "Comment: For customer", which causes irregularities with the "time to first response"-report... therefore the report isn't reliable.

            Stefanie Flek added a comment - As described in the summary: I have the problem, when an agent is also request participant in a ticket and comments for  the customer, it does not count for the SLA "Comment: For customer", which causes irregularities with the "time to first response"-report... therefore the report isn't reliable.

            Bartosz Ornatowski added a comment -

            Hi there,

            We have published a Knowledge Base article that may help with the notification aspect of this problem.

            You'll find the information you need here: https://confluence.atlassian.com/jirakb/enabling-notifications-for-agents-acting-as-customers-987144325.html

            Thank you,

            The Jira Service Desk Team

            Bartosz Ornatowski added a comment - Hi there, We have published a Knowledge Base article that may help with the notification aspect of this problem. You'll find the information you need here:  https://confluence.atlassian.com/jirakb/enabling-notifications-for-agents-acting-as-customers-987144325.html Thank you, The Jira Service Desk Team

              Unassigned Unassigned
              vdung Andy Nguyen (Inactive)
              Votes:
              59 Vote for this issue
              Watchers:
              40 Start watching this issue

                Created:
                Updated: