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

      Problem Definition

      When we're configuring the customers notifications, there's no option to customize it according to request types. For instance, I'd like the notification regarding issue created to be sent for the request types X and Y, but not for Z.

      Suggest Solution

      Add the ability to do so.

      Workaround

      Use the automation rules from Service Desk for certain events such as:

      When: Issue Created
      If: Issue matches -> "Customer Request Type" = X
      Then: Send email

            [JSDSERVER-5624] Customize notifications per Request Type

            +1 this should be standard functaionality please.

            Lucy Alvarez added a comment - +1 this should be standard functaionality please.

            +1 This would be VERY helpful

            Gregg Reaves added a comment - +1 This would be VERY helpful

            Atlassian client, Universal Music, needs this capability. 

            Parolini (Inactive) added a comment - Atlassian client, Universal Music, needs this capability. 

            Yes, we also want this capability.

            Efren Miguel added a comment - Yes, we also want this capability.

            Our use case:

            only specific requests which have approval process should notify the approvers
            for  example request type X has approval process in it and we want to notify the approvers (customer notification)
            and request type Y also has approval process,but it should not notify the approvers

            pottururahul09 added a comment - Our use case: only specific requests which have approval process should notify the approvers for  example request type X has approval process in it and we want to notify the approvers (customer notification) and request type Y also has approval process,but it should not notify the approvers

            My need:

            Notify (email) specific approvers (members of a Role) based on the Request Type of the issue raised.

            My example.  We have a JSD project that handles purchase requests for a large department with multiple divisions.  Each division has its own request type.  When someone raises a request from a specific division, we need to notify that division's budget area Approver to review the request.

            Constraints.  We cannot give every requester a list of all the approvers in the department.  Employees may not know their budget area approver.  They may confuse their budget area approver with their direct supervisor.  Critical: we need to notify a Role, not an individual, for two reasons.  A) we want to notify a primary approver and back-up approvers at the same time, in case someone is out of the office.  B) Jira project leads can edit Roles as people change their employment status.  We don't want to force changes to be made by a Jira admin.  The project lead is closer to the department, may even be a department member, and will be more aware of employment changes that the Jira admins.

            Chrisjir Parkin added a comment - My need: Notify (email) specific approvers (members of a Role) based on the Request Type of the issue raised. My example.  We have a JSD project that handles purchase requests for a large department with multiple divisions.  Each division has its own request type.  When someone raises a request from a specific division, we need to notify that division's budget area Approver to review the request. Constraints.  We cannot give every requester a list of all the approvers in the department.  Employees may not know their budget area approver.  They may confuse their budget area approver with their direct supervisor.  Critical : we need to notify a Role , not an individual, for two reasons.  A) we want to notify a primary approver and back-up approvers at the same time, in case someone is out of the office.  B) Jira project leads can edit Roles as people change their employment status.  We don't want to force changes to be made by a Jira admin.  The project lead is closer to the department, may even be a department member, and will be more aware of employment changes that the Jira admins.

            I want to take this a little further. The system should allow the content for each request type to be independently configurable.

            So what the notification for request type X is can be different from request type y and both of those are different from request type Z content.

            Stephen Pavlik added a comment - I want to take this a little further. The system should allow the content for each request type to be independently configurable. So what the notification for request type X is can be different from request type y and both of those are different from request type Z content.

            In the environment where more than one IT team is a resident of a single IT Service Desk, this is a key feature.

            Scenario, all IT Teams are in one HelpDesk

            • Desktop Support
            • DBA
            • SysAdmins
            • InfoSec
            • Networking

             

            When the ticket arrives to the queue of a specific team, we need to be able to notify the team of agents that owns the specific queue

            Andrew Bilukha added a comment - In the environment where more than one IT team is a resident of a single IT Service Desk, this is a key feature. Scenario, all IT Teams are in one HelpDesk Desktop Support DBA SysAdmins InfoSec Networking   When the ticket arrives to the queue of a specific team, we need to be able to notify the team of agents that owns the specific queue

              Unassigned Unassigned
              pahennig Paulo Hennig (Inactive)
              Votes:
              97 Vote for this issue
              Watchers:
              41 Start watching this issue

                Created:
                Updated: