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??

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?

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.

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.

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.