Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-971

Allow customization of the Service Desk notifications to customers

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

      There is currently no method to customize the notifications in Service Desk (it is either enabled or disabled, no modifications are possible).

      This makes it impossible to change who should/should not receive notifications when using the Service Desk notifications, and which operations shouldn't trigger a notification.

      It would be much more convenient if we can modify the Service Desk notifications.

            [JSDCLOUD-971] Allow customization of the Service Desk notifications to customers

            I searched for information on the Internet and found material that helped me, link

            Vitaly_Berezovsky_SaaSJet added a comment - I searched for information on the Internet and found material that helped me, link

            Can you give an approximate date for the next major server release, 2 weeks,1 months or a year??

            Michael Hönes added a comment - Can you give an approximate date for the next major server release, 2 weeks,1 months or a year??

            Hi all,

            Great news - customization of service desk notifications is now available on Cloud! To find out more about this feature, check out our documentation here: https://confluence.atlassian.com/servicedeskcloud/managing-service-desk-notifications-732528936.html. This feature will be available for Server in an upcoming major server release.

            A few of you have asked about disabling account creation emails (i.e welcome emails). JSD-971 does not provide this capability as the welcome emails are sent per instance on account creation, not per service desk project. If this is something you are interested in, please vote for and watch the existing suggestion JSD-1708 - Disable Welcome E-Mail to New Customers, for future updates.

            Enjoy customizing your project's email notifications! 

            — JIRA Service Desk Team

            V (Inactive) added a comment - Hi all, Great news - customization of service desk notifications is now available on Cloud! To find out more about this feature, check out our documentation here:  https://confluence.atlassian.com/servicedeskcloud/managing-service-desk-notifications-732528936.html . This feature will be available for Server in an upcoming major server release. A few of you have asked about disabling account creation emails (i.e welcome emails). JSD-971 does not provide this capability as the welcome emails are sent per instance on account creation, not per service desk project. If this is something you are interested in, please vote for and watch the existing suggestion JSD-1708 - Disable Welcome E-Mail to New Customers, for future updates. Enjoy customizing your project's email notifications!  — JIRA Service Desk Team

            No problem Jo-Ann, I'm glad it helped. What other issues are you still getting with JIRA SD?

            Dan Hellings added a comment - No problem Jo-Ann, I'm glad it helped. What other issues are you still getting with JIRA SD?

            Hi Dan,
            Yes we tweaked the notifications scheme & it helped. Appreciate your guidance. Still major issues with Jira SD for external use.

            Jo-Ann Calcagno added a comment - Hi Dan, Yes we tweaked the notifications scheme & it helped. Appreciate your guidance. Still major issues with Jira SD for external use.

            Hi Jo-Ann, have you tried changing the workflow 'Status Name to show customer' to be something generic like 'IT Investigating'? If you have then please ignore the below:

            Service Desk workflow statuses have two names - one is the 'workflow status in JIRA' name (e.g. in progress, on hold etc.) but each status also has a customer display name called 'Status name to show the customer'. So you leave the 'workflow status in JIRA' name the same (in-progress to-do etc.), but change each of their 'status name to show the customer'... name to be the same for all the statuses where you do not want notifications to be sent out (e.g. IT Investigating), then it will only trigger notifications if the 'Status name to show the customer' changes.

            I hope that made some sense?

            In the scenario below only 1,5,6 and 7 will send notifications as that display name has changed.

            Workflow Status Name in JIRA -----> Status name to show customer:

            1- Open -----> IT Investigating
            2- Awaiting prioritisation -----> IT Investigating
            3- In progress ------> IT Investigating
            4- Awaiting approval ------> IT Investigating
            5- Waiting for customer ------> Requester action required
            6- Waiting for support -----> IT Investigating
            7- Resolved ------> Resolved

            To change the 'Status name to show the customer' in JIRA 7 go to your Service Desk settings page. Click on Request types in the side bar. Then click on Edit Fields in the Actions column on the main page (for each issue type!). Click on the 'Workflow Statuses' tab and change the appropriate names and click save.

            I hope some of that rambling made some sense. If not then reply and I will try to explain it a bit better.

            Dan Hellings added a comment - Hi Jo-Ann, have you tried changing the workflow 'Status Name to show customer' to be something generic like 'IT Investigating'? If you have then please ignore the below: Service Desk workflow statuses have two names - one is the 'workflow status in JIRA' name (e.g. in progress, on hold etc.) but each status also has a customer display name called 'Status name to show the customer'. So you leave the 'workflow status in JIRA' name the same (in-progress to-do etc.), but change each of their 'status name to show the customer'... name to be the same for all the statuses where you do not want notifications to be sent out (e.g. IT Investigating), then it will only trigger notifications if the 'Status name to show the customer' changes. I hope that made some sense? In the scenario below only 1,5,6 and 7 will send notifications as that display name has changed. Workflow Status Name in JIRA -----> Status name to show customer: 1- Open -----> IT Investigating 2- Awaiting prioritisation -----> IT Investigating 3- In progress ------> IT Investigating 4- Awaiting approval ------> IT Investigating 5- Waiting for customer ------> Requester action required 6- Waiting for support -----> IT Investigating 7- Resolved ------> Resolved To change the 'Status name to show the customer' in JIRA 7 go to your Service Desk settings page. Click on Request types in the side bar. Then click on Edit Fields in the Actions column on the main page (for each issue type!). Click on the 'Workflow Statuses' tab and change the appropriate names and click save. I hope some of that rambling made some sense. If not then reply and I will try to explain it a bit better.

            We are getting grief from all regarding the unnecessary notifications. Internal & external customers are annoyed & some are refusing to use system.This issue along with the lack of distribution groups & customization of auto replies..... there's talk of pulling the plug if Atlassian doesn't move faster to incorporate basic out of the box ticketing system features.

            Jo-Ann Calcagno added a comment - We are getting grief from all regarding the unnecessary notifications. Internal & external customers are annoyed & some are refusing to use system.This issue along with the lack of distribution groups & customization of auto replies..... there's talk of pulling the plug if Atlassian doesn't move faster to incorporate basic out of the box ticketing system features.

            Would be nice if there was a checkbox on each workflow transition wheter to send out notificaton or not.

            Alf Karlsen added a comment - Would be nice if there was a checkbox on each workflow transition wheter to send out notificaton or not.

            We want to run service desk in a smallish team at a large company not familiar with JIRA and the inability to customize any aspect of the email notifications has made this something of a non-starter.

            A typical example of it costing us time/money would be an email to ~5 people + 2 distribution lists that includes our helpdesk alias as a cc. We will then send the following emails:
            1 to the reporter (not ok - we were on the cc and there is no ticket for us to solve)
            1 to each of the 5 participants (not ok, this wasn't for us to solve it was just an fyi and we've just spammed 5 people)
            1 to each of the DLs telling them we've created an accout for them (not ok, it's a DL - don't create a account and tell everyone in the list about it!)
            1 to each of the DLs telling them they've been added as a participant (again, not ok for all the previous reasons)

            So we're up 10 emails that are now taking people time to read and we haven't even done anything useful.

            on top of that when we then resolve the ticket (which we didn't want in the first place) we send another email to everyone on the list to tell them we resolved a ticket which none of them care about.

            The only way to use the system as it currently stands is to completely turn off email notifications

            David Tyler added a comment - We want to run service desk in a smallish team at a large company not familiar with JIRA and the inability to customize any aspect of the email notifications has made this something of a non-starter. A typical example of it costing us time/money would be an email to ~5 people + 2 distribution lists that includes our helpdesk alias as a cc. We will then send the following emails: 1 to the reporter (not ok - we were on the cc and there is no ticket for us to solve) 1 to each of the 5 participants (not ok, this wasn't for us to solve it was just an fyi and we've just spammed 5 people) 1 to each of the DLs telling them we've created an accout for them (not ok, it's a DL - don't create a account and tell everyone in the list about it!) 1 to each of the DLs telling them they've been added as a participant (again, not ok for all the previous reasons) So we're up 10 emails that are now taking people time to read and we haven't even done anything useful. on top of that when we then resolve the ticket (which we didn't want in the first place) we send another email to everyone on the list to tell them we resolved a ticket which none of them care about. The only way to use the system as it currently stands is to completely turn off email notifications

            example use case.

            Setting SLA that can be pause if agent would need a break/go to meeting, kind of like the Avaya telephone system. It is possible to configure the SLA to pause when it goes into a 'pause' status, however, notification will be send to customer regarding this and its not convenient for customer to receive all these notification.

            Azfar Masut (Inactive) added a comment - example use case. Setting SLA that can be pause if agent would need a break/go to meeting, kind of like the Avaya telephone system. It is possible to configure the SLA to pause when it goes into a 'pause' status, however, notification will be send to customer regarding this and its not convenient for customer to receive all these notification.

            Don Ramsey added a comment -

            An on/off switch per project would be an excellent start - since I know making configurable switches per customer like for agents will be a lot harder and take longer.

            Don Ramsey added a comment - An on/off switch per project would be an excellent start - since I know making configurable switches per customer like for agents will be a lot harder and take longer.

            For our company it is also very important to decide when a notification is send out and when not. There are a lot of unnecessary notifications currently.

            Michael Hönes added a comment - For our company it is also very important to decide when a notification is send out and when not. There are a lot of unnecessary notifications currently.

            This should really already be available for the customer role. Notification schemes allow adding the customer role to certain notifications, but then they are just never sent. We can be expected to give a customer the full agent role when they just want to receive an email when an issue is created or commented etc. These types of users often never login to the portal or reply, they just want to see the activity in their in box.

            Thanks!

            Pat Honeycutt added a comment - This should really already be available for the customer role. Notification schemes allow adding the customer role to certain notifications, but then they are just never sent. We can be expected to give a customer the full agent role when they just want to receive an email when an issue is created or commented etc. These types of users often never login to the portal or reply, they just want to see the activity in their in box. Thanks!

            Christa_Prins added a comment - - edited

            Hi,
            We are using Jira Service Desk (cloud) for 2 months now and we (users) are very happy with it. However my management is reconsidering to stop with Jira due to the unprofessional notifications it is sending and that we are not able to stop this. We disabled some notifications but Jira is sending in anyhow, it is annoying our customers!
            Please urgently implement this.
            Our issue #JST-181145
            BR,
            Christa

            p.s. I forgot to mention that we are using Jira locally and next week someone from our HQ is coming over to discuss Jira!

            Christa_Prins added a comment - - edited Hi, We are using Jira Service Desk (cloud) for 2 months now and we (users) are very happy with it. However my management is reconsidering to stop with Jira due to the unprofessional notifications it is sending and that we are not able to stop this. We disabled some notifications but Jira is sending in anyhow, it is annoying our customers! Please urgently implement this. Our issue #JST-181145 BR, Christa p.s. I forgot to mention that we are using Jira locally and next week someone from our HQ is coming over to discuss Jira!

            BTW, we bought a Service Desk license but can not use it because this important feature is missing. Please consider implementing it asap. Thanks.

            ilfak guilfanov added a comment - BTW, we bought a Service Desk license but can not use it because this important feature is missing. Please consider implementing it asap. Thanks.

            Urgently require this feature.

            Teri Baines added a comment - Urgently require this feature.

            KS added a comment - - edited

            My problem is my customers are not getting any notifications (other than when it's created, commented or closed/resolved). What's the point of having the option of changing the workflow statuses for each request type that is shown to the customer, if they can't get notified of the change to the ticket? Am I doing something wrong? Atlassian support is giving me the run around saying there is no functionality for the customer to get notifications other than those, but that completely contradicts 1. How the program allows for status schemes all together and 2. Multiple instruction documents saying it's possible.

            KS added a comment - - edited My problem is my customers are not getting any notifications (other than when it's created, commented or closed/resolved). What's the point of having the option of changing the workflow statuses for each request type that is shown to the customer, if they can't get notified of the change to the ticket? Am I doing something wrong? Atlassian support is giving me the run around saying there is no functionality for the customer to get notifications other than those, but that completely contradicts 1. How the program allows for status schemes all together and 2. Multiple instruction documents saying it's possible.

            Hi,

            We consider this a fundamental requirement and it should be implemented.

            Thanks,

            bernard gorman
            Samsung, Cambridge

            Bernard Gorman added a comment - Hi, We consider this a fundamental requirement and it should be implemented. Thanks, bernard gorman Samsung, Cambridge

            Joeann added a comment -

            Thanks Dan. I will try these settings and let you know if it works for me.

            Joeann added a comment - Thanks Dan. I will try these settings and let you know if it works for me.

            Dan Hellings added a comment - - edited

            Hi Joeann, have you tried updating the customer facing statuses as this resolved the constant emails being sent to customers for us? As long as the customer facing status is the same when the issue transitions through different steps then no emails are sent out.

            Example:

            Status | Customer Status | Result

            • New > IT Investigating > New Issue Email Sent
            • In Triage > IT Investigating > No Email
            • Awaiting Resource > IT Investigating > No Email
            • Awaiting Approval > IT Investigating > No Email
            • Pending > IT Investigating > No Email
            • On Hold > On Hold > Email sent advising On Hold (an email is sent when call is taken off hold as well)
            • In Progress > IT Investigating > No Email
            • Resolved > Resolved > Email sent advising issue is resolved

            Dan Hellings added a comment - - edited Hi Joeann, have you tried updating the customer facing statuses as this resolved the constant emails being sent to customers for us? As long as the customer facing status is the same when the issue transitions through different steps then no emails are sent out. Example: Status | Customer Status | Result New > IT Investigating > New Issue Email Sent In Triage > IT Investigating > No Email Awaiting Resource > IT Investigating > No Email Awaiting Approval > IT Investigating > No Email Pending > IT Investigating > No Email On Hold > On Hold > Email sent advising On Hold (an email is sent when call is taken off hold as well) In Progress > IT Investigating > No Email Resolved > Resolved > Email sent advising issue is resolved

            Joeann added a comment - - edited

            This is a very important feature that should be implemented

            To be honest, the JIRA notifications are irritating as multiple notifications get triggered as an email and customizing to check which ones should get triggered is VERY IMPORTANT FEATURE REQUEST.

            I've infact received an email from the customer itself stating these notifications are irritating and that they need to be turned of.
            I agree with Dan as there is no solution except to turn off the JIRA notifications completely.

            Joeann added a comment - - edited This is a very important feature that should be implemented To be honest, the JIRA notifications are irritating as multiple notifications get triggered as an email and customizing to check which ones should get triggered is VERY IMPORTANT FEATURE REQUEST. I've infact received an email from the customer itself stating these notifications are irritating and that they need to be turned of. I agree with Dan as there is no solution except to turn off the JIRA notifications completely.

            In JIRA 6, we set everything up so the customer was getting notified of all the things they wanted via the Notification Schemes and they have now gotten an automatic update to JIRA 7 which completely changes the way customers of JSD are notified (basically, you can't control customer notifications anymore because the Notification Schemes are only applied to agents).

            Dimitri Lemmens added a comment - In JIRA 6, we set everything up so the customer was getting notified of all the things they wanted via the Notification Schemes and they have now gotten an automatic update to JIRA 7 which completely changes the way customers of JSD are notified (basically, you can't control customer notifications anymore because the Notification Schemes are only applied to agents).

            Leo Vogel added a comment -

            Dan,

            What we've done is to set the customer facing status to be the same for all status except for Resolved. So when one of our clients submits a request the status they see is "Received - In Progress" but in JSD we see "Waiting for Triage". You set this up by going to your support project, editing the request types, clicking edit fields, then at the top choose the "Workflow Statuses" tab. Transition emails won't be sent to customers if the customer status is the same for the previous status and the transitioned to status.

            I hope this helps!

            -Leo

            Leo Vogel added a comment - Dan, What we've done is to set the customer facing status to be the same for all status except for Resolved. So when one of our clients submits a request the status they see is "Received - In Progress" but in JSD we see "Waiting for Triage". You set this up by going to your support project, editing the request types, clicking edit fields, then at the top choose the "Workflow Statuses" tab. Transition emails won't be sent to customers if the customer status is the same for the previous status and the transitioned to status. I hope this helps! -Leo

            I fixed this by setting e-mail notifications OFF, and using the JIRA Webhook to send issue:created and issue:updated JSON data to our webserver. On this webserver I am processing the JSON and I've set up some simple rules to e-mail customers from there.

            David Schaap added a comment - I fixed this by setting e-mail notifications OFF, and using the JIRA Webhook to send issue:created and issue:updated JSON data to our webserver. On this webserver I am processing the JSON and I've set up some simple rules to e-mail customers from there.

            Dan Hellings added a comment - - edited

            We have been trying to get our Service Desk to send emails when an item is created, when an item is resolved/closed and also when a external comment is added (the same scenario as James mentioned above).

            We originally setup a notification scheme in the project site for Service Desk and set it to do the above. When we tested this it turns out that emails were still being sent out for transitioning between statuses. It turns out Service Desk has an overriding setting that will always send out emails for certain scenarios, including status transitions. A recommended fix for this was to simply switch the Service Desk Notification setting off (at the system admin level). This did not work as with this switched off Service Desk reverted to the JIRA project notification, and in doing so emails were sent out for external and Internal comments! This is because the notification scheme treats comments as the same. A further issue with this was the fact non-JIRA license holders didn't get emailed at all!

            We have tried numerous help guides, Atlassian support etc. and it looks as though there is no way around this.

            Due to this we have had to think outside of JIRA in trying to find a (pretty nasty) solution. What we are possibly thinking of doing is to add an email rule to block any emails from the Service Desk email address to the Customers that contain certain text in the body of the email itself. The issue with this is that the status emails contain a trail of all the past updates. So if you block anything with "Your request status changed to IN PROGRESS" within it, then the Resolved/Closed email will also get blocked as it displays in the previous updates part at the bottom of the email the "Your request status changed to IN PROGRESS" note. The only unique way to add these rules as far as we can see is is if you add a rule to block/drop the emails from the ServiceDesk email address that contain the following:

            IN PROGRESS
            Your request status changed to In Progress.

            You will have to add a rule for each of the status emails that you do not want emails to be sent out for (e.g. On Hold etc.). You will also need to make sure that this would work for you and whether this would block any emails that you would like to be sent. We went through each scenario and looked at the email that was sent and made a call on it that way.

            i thought i would share our pain on this matter and the lengths we have had to go to stop emails that you would imagine would be a simple setting for a Application of this type.

            UPDATE: Following on from Leo's comment below we have updated the Customer Facing status to be the same for the notifications where we do not want to send notifications and this works as expected and resolved the issue for us. We have numerous statuses for New and In-Progress steps, but we have two customer facing notifications - IT Investigating and on Hold.

            Dan Hellings added a comment - - edited We have been trying to get our Service Desk to send emails when an item is created, when an item is resolved/closed and also when a external comment is added (the same scenario as James mentioned above). We originally setup a notification scheme in the project site for Service Desk and set it to do the above. When we tested this it turns out that emails were still being sent out for transitioning between statuses. It turns out Service Desk has an overriding setting that will always send out emails for certain scenarios, including status transitions. A recommended fix for this was to simply switch the Service Desk Notification setting off (at the system admin level). This did not work as with this switched off Service Desk reverted to the JIRA project notification, and in doing so emails were sent out for external and Internal comments! This is because the notification scheme treats comments as the same. A further issue with this was the fact non-JIRA license holders didn't get emailed at all! We have tried numerous help guides, Atlassian support etc. and it looks as though there is no way around this. Due to this we have had to think outside of JIRA in trying to find a (pretty nasty) solution. What we are possibly thinking of doing is to add an email rule to block any emails from the Service Desk email address to the Customers that contain certain text in the body of the email itself. The issue with this is that the status emails contain a trail of all the past updates. So if you block anything with "Your request status changed to IN PROGRESS" within it, then the Resolved/Closed email will also get blocked as it displays in the previous updates part at the bottom of the email the "Your request status changed to IN PROGRESS" note. The only unique way to add these rules as far as we can see is is if you add a rule to block/drop the emails from the ServiceDesk email address that contain the following: IN PROGRESS Your request status changed to In Progress. You will have to add a rule for each of the status emails that you do not want emails to be sent out for (e.g. On Hold etc.). You will also need to make sure that this would work for you and whether this would block any emails that you would like to be sent. We went through each scenario and looked at the email that was sent and made a call on it that way. i thought i would share our pain on this matter and the lengths we have had to go to stop emails that you would imagine would be a simple setting for a Application of this type. UPDATE: Following on from Leo's comment below we have updated the Customer Facing status to be the same for the notifications where we do not want to send notifications and this works as expected and resolved the issue for us. We have numerous statuses for New and In-Progress steps, but we have two customer facing notifications - IT Investigating and on Hold.

            I am trying to tweak the notification scheme to only send emails in the following conditions:

            1. Issue create
            2. Issue close/resolved
            3. Issue commented on

            The system doesn't always send out emails. It never sends out emails when closed or resolved. It also sends out emails with internal comments to customers.

            Please advise how to correct the internal communications being emails and how to set it up correctly to handle the request (1 - 3) above.

            James Glover added a comment - I am trying to tweak the notification scheme to only send emails in the following conditions: 1. Issue create 2. Issue close/resolved 3. Issue commented on The system doesn't always send out emails. It never sends out emails when closed or resolved. It also sends out emails with internal comments to customers. Please advise how to correct the internal communications being emails and how to set it up correctly to handle the request (1 - 3) above.

            The change done in cloud a month ago which changed the way notifications look like and removed the notifications being sent on customer-visible statuses is a big downgrade of what we liked in Service Desk notification, making this ticket even more important to implement.

            Peter Bengov added a comment - The change done in cloud a month ago which changed the way notifications look like and removed the notifications being sent on customer-visible statuses is a big downgrade of what we liked in Service Desk notification, making this ticket even more important to implement.

            @AMN systems, dude, you rock! This has helped us so much.. and know we are a paying customer because of you.

            David Schaap added a comment - @AMN systems, dude, you rock! This has helped us so much.. and know we are a paying customer because of you.

            AMN Systems added a comment - - edited

            For people who are, like me, waiting for JIRA to properly fix this issue there is a work-around possible. What I did is the following:

            Create a webhook in System > Webhooks that points to a URL (http://example.com/webhooks/servicedesk.php)
            Modify the workflow of the service desk (Issues > Workflow).
            Edit the transitions that need to send mails (note the transition IDs);
            Add a "Post Function" calling the Webhook you created.

            A sample of the script I created in PHP:

            <?php
            // get JSON input from HTTP request
            $body = @file_get_contents('php://input');
            $body = json_decode($body, true);
            
            // Set TO address
            $to      = $body["issue"]["fields"]["creator"]["emailAdress"];
            // Set subject
            $subject = 'Helpdesk ('.$body["issue"]["key"].') '.$body["issue"]["fields"]["summary"];
            // Set headers
            $headers = 'From: Helpdesk <helpdesk@example.com>' . "\r\n" .
                'Reply-To: Helpdesk <helpdesk@example.com>' . "\r\n" .
                'X-Mailer: PHP/' . phpversion();
            
            // decide what message to send based on transition ID. 
            if($body["transition"]["transitionId"] == 1) {
            $message = 'Hello '.$body["issue"]["fields"]["creator"]["displayName"].',
            
            '.$body["comment"].'
            
            Kind regards,
            
            '.$body["user"]["displayName"];
            }
            // Send the actual email
            mail($to, $subject, $message, $headers);
            ?>
            

            Hopefully this helps some people!

            AMN Systems added a comment - - edited For people who are, like me, waiting for JIRA to properly fix this issue there is a work-around possible. What I did is the following: Create a webhook in System > Webhooks that points to a URL ( http://example.com/webhooks/servicedesk.php ) Modify the workflow of the service desk (Issues > Workflow). Edit the transitions that need to send mails (note the transition IDs); Add a "Post Function" calling the Webhook you created. A sample of the script I created in PHP: <?php // get JSON input from HTTP request $body = @file_get_contents( 'php: //input' ); $body = json_decode($body, true ); // Set TO address $to      = $body[ "issue" ][ "fields" ][ "creator" ][ "emailAdress" ]; // Set subject $subject = 'Helpdesk (' .$body[ "issue" ][ "key" ]. ') ' .$body[ "issue" ][ "fields" ][ "summary" ]; // Set headers $headers = 'From: Helpdesk <helpdesk@example.com>' . "\r\n" .     'Reply-To: Helpdesk <helpdesk@example.com>' . "\r\n" .     'X-Mailer: PHP/' . phpversion(); // decide what message to send based on transition ID.  if ($body[ "transition" ][ "transitionId" ] == 1) { $message = 'Hello ' .$body[ "issue" ][ "fields" ][ "creator" ][ "displayName" ].', '.$body[ "comment" ].' Kind regards, '.$body[ "user" ][ "displayName" ]; } // Send the actual email mail($to, $subject, $message, $headers); ?> Hopefully this helps some people!

            This feature is extremely important for our helpdesk. Please take this suggestion into serious considderation

            AMN Systems added a comment - This feature is extremely important for our helpdesk. Please take this suggestion into serious considderation

            I put my ass on the line to implement Jira Service Desk! THIS IS A SHOW STOPPER, for me.

            Doug Aliff added a comment - I put my ass on the line to implement Jira Service Desk! THIS IS A SHOW STOPPER , for me.

            I need this feature for start operations.

            Luis Herrera added a comment - I need this feature for start operations.

            We can't move to JIRA Service Desk right now because of the lacking of this feature... Waiting for it!

            David Schaap added a comment - We can't move to JIRA Service Desk right now because of the lacking of this feature... Waiting for it!

            Customer would like to prevent JIRA Service Desk from sending notifications of Account created to his customers that send email to his Service Desk and do not have a JIRA Service Desk email before.

            Ismael Olusula Jimoh (Inactive) added a comment - Customer would like to prevent JIRA Service Desk from sending notifications of Account created to his customers that send email to his Service Desk and do not have a JIRA Service Desk email before.

            Our company has been forced to completely disable the Service Desk notifications and rely on more manual communication with our customers and internally because of this problem; a fix would be much appreciated.

            Hannah Hawkins added a comment - Our company has been forced to completely disable the Service Desk notifications and rely on more manual communication with our customers and internally because of this problem; a fix would be much appreciated.

            JasonJ added a comment -

            I can't seem to vote or watch this issue. This feature is very much needed.

            JasonJ added a comment - I can't seem to vote or watch this issue. This feature is very much needed.

            Michael Bremer added a comment - - edited

            We also this need feature urgently!

            Michael Bremer added a comment - - edited We also this need feature urgently!

            100% agree, this feature needs to be implemented asap.

            Ronald Balk added a comment - 100% agree, this feature needs to be implemented asap.

            This is a required feature for making JIRA Service Desk Enterprise ready.

            Alf Karlsen added a comment - This is a required feature for making JIRA Service Desk Enterprise ready.

            The more i use service desk, the more i get annoyed by the amount of senseless notifications that are sent and which can't be switched off.
            can't u please at least let us know if this is going to change? can't u integrate the status-changed-notifications into the notification scheme?

            David Vogel added a comment - The more i use service desk, the more i get annoyed by the amount of senseless notifications that are sent and which can't be switched off. can't u please at least let us know if this is going to change? can't u integrate the status-changed-notifications into the notification scheme?

            i 100% agree. Its a must feature for a good service desk. i like jira, but its a reason to discontinue using cloud version of service desk. pls jira team, give this issue more importance. can u draw a timeline on that?
            it can't be so hard to give us this feature.

            David Vogel added a comment - i 100% agree. Its a must feature for a good service desk. i like jira, but its a reason to discontinue using cloud version of service desk. pls jira team, give this issue more importance. can u draw a timeline on that? it can't be so hard to give us this feature.

            Absolutely agree. We have similar issues, especially with many of our customers frequent users, so the email traffic this creates is actually unproductive. We will need to err on the side of caution and switch off Service Desk notifications because of this.

            Chris Sedler added a comment - Absolutely agree. We have similar issues, especially with many of our customers frequent users, so the email traffic this creates is actually unproductive. We will need to err on the side of caution and switch off Service Desk notifications because of this.

            This is a big issue for us. Customers get a lot of email from service desk. I would like to configure JSD to only send emails when we comment on a request.

            Brad Nelson added a comment - This is a big issue for us. Customers get a lot of email from service desk. I would like to configure JSD to only send emails when we comment on a request.

            Thanks Julio, (gracias)

            TINSA TASACIONES INMOBILIARIAS added a comment - Thanks Julio, (gracias)

            Antonio,
            The feature may look greyed out.
            If you just start typing, it will take your value. Hit save at the bottom and you're set.

            I thought I had the same issue, but after trying, it worked.

            This work around works, albeit with some caveats.
            When I changed the Customer Status for the Resolved stage, helpdesk technicians started noticing that comments entered using the "insert issue here..." at the bottom of an issue will not generate an email to customers.

            Julio Ochoa added a comment - Antonio, The feature may look greyed out. If you just start typing, it will take your value. Hit save at the bottom and you're set. I thought I had the same issue, but after trying, it worked. This work around works, albeit with some caveats. When I changed the Customer Status for the Resolved stage, helpdesk technicians started noticing that comments entered using the "insert issue here..." at the bottom of an issue will not generate an email to customers.

            Hey Benedikt,
            I can not change the name to the option you mention me (Status name to show costumer), the option is disabled.
            Thanks

            TINSA TASACIONES INMOBILIARIAS added a comment - Hey Benedikt, I can not change the name to the option you mention me (Status name to show costumer), the option is disabled. Thanks

            I see what you mean.
            It doesn't look like I can modify the value under "Status name to show customer" for some of the statuses in my workflow. I tweaked the default workflow to add an internal Escalation status.
            I may have to change it in the status properties in the workflow to achieve this. What a drag...

            Julio Ochoa added a comment - I see what you mean. It doesn't look like I can modify the value under "Status name to show customer" for some of the statuses in my workflow. I tweaked the default workflow to add an internal Escalation status. I may have to change it in the status properties in the workflow to achieve this. What a drag...

            Hey Julia,

            any change between statuses that share the same status name will not trigger a notification. Comments, assigning a new Admin and so on however DO trigger a notification. I assure you, this is what you want.

            Hell, Atlassian, fix that damn docu to state that more obvious.

            Benedikt Koller added a comment - Hey Julia, any change between statuses that share the same status name will not trigger a notification. Comments, assigning a new Admin and so on however DO trigger a notification. I assure you, this is what you want. Hell, Atlassian, fix that damn docu to state that more obvious.

            Benedikt,
            So you made the "Status name to show customer" all the same ("Waiting for Support").
            Does this somehow trick SD not to send a notification when the status changes?
            What about when comments are inserted in the issue? Do customers get those?

            Julio Ochoa added a comment - Benedikt, So you made the "Status name to show customer" all the same ("Waiting for Support"). Does this somehow trick SD not to send a notification when the status changes? What about when comments are inserted in the issue? Do customers get those?

            Benedikt Koller added a comment - - edited

            Hi Julia,

            if you follow through you with the posted guide you will achieve something like the following:

            As long as the statusname on the right does not change no notification will be triggered. We achieved a setup exactly like the one you mentioned.

            But I however agree that this is a hack, horrible user experience and raises questions about the design process of things.

            EDIT: Sorry about that huge image, fixed it now.

            Benedikt Koller added a comment - - edited Hi Julia, if you follow through you with the posted guide you will achieve something like the following: As long as the statusname on the right does not change no notification will be triggered. We achieved a setup exactly like the one you mentioned. But I however agree that this is a hack, horrible user experience and raises questions about the design process of things. EDIT: Sorry about that huge image, fixed it now.

            Benedikt,
            I looked at your suggestion and I'm not sure how it addressed the SD notifications customization issues or how it answers Antonio's request.
            We're in a similar spot. SD generates way too many emails. It'd be great if we could customize the notification scheme for SD so customers get notified only when the issue is assigned, commented, and resolved.
            It's interesting how there are notification schemes available for all projects that let you customize what actions generate emails, but there isn't an option like that for the SD.

            Julio Ochoa added a comment - Benedikt, I looked at your suggestion and I'm not sure how it addressed the SD notifications customization issues or how it answers Antonio's request. We're in a similar spot. SD generates way too many emails. It'd be great if we could customize the notification scheme for SD so customers get notified only when the issue is assigned, commented, and resolved. It's interesting how there are notification schemes available for all projects that let you customize what actions generate emails, but there isn't an option like that for the SD.

            Hey Antonio,

            for us this fixed it: https://confluence.atlassian.com/display/SERVICEDESK/Setting+up+request+types#Settinguprequesttypes-CustomizingWorkflowCustomizingtheworkflowstatusesforarequesttype

            Simply go to the Service Desk you want to modify, go to Settings, Request Types, click on Edit Fields and then switch to the "Fields" tab - the link can be confusing on how to get there.

            Benedikt Koller added a comment - Hey Antonio, for us this fixed it: https://confluence.atlassian.com/display/SERVICEDESK/Setting+up+request+types#Settinguprequesttypes-CustomizingWorkflowCustomizingtheworkflowstatusesforarequesttype Simply go to the Service Desk you want to modify, go to Settings, Request Types, click on Edit Fields and then switch to the "Fields" tab - the link can be confusing on how to get there.

              Unassigned Unassigned
              jtye Joe Wai Tye (Inactive)
              Votes:
              200 Vote for this issue
              Watchers:
              149 Start watching this issue

                Created:
                Updated:
                Resolved: