We just Moved to JSM and would love to see this be a thing as we had it in our old software.

+1

I'd like to remove the two "estimate" fields from our agent notifications as they are not needed

This would save admins so much time in managing automation rules.  Please add this to the next release!

I would like that.

About to move to Jira Service Management - and find these emails Terrible.    The email describes in 5 different ways that a ticket has been assigned to me - but doesn't tell me anything about what the ticket is.  I have to log into look.   I cant look quickly at the email and decide if I need to move to that ticket or not.   

Atlassian-

It looks like this issue is currently assigned to a former employee, d7c36792fcf8 (inactive). Could you provide an update on where this request is for prioritization?

It seems like the built-in notifications shouldn't require creating a custom notification system to be able to change the fields included. As an interim step, could you preconfigure an automation that's available for download as JSON file with some of the most common fields agents would need to see?

Would like to add the ticket 'Request Type' to emails.

+1

Would love to see this, especially in combination with another request - https://jira.atlassian.com/browse/JSDCLOUD-7807

Being able to selectively choose templates, the recipient (agent vs customer/participant), and which issue/request types get the notifications.. etc

Doing all of this via automation is possible but you could still run into automation restrictions on licensing, not to mention, architecting the entire thing.

+1

+1

Many reasons why this is needed and the workaround is not particularly feasible 

We've resorted to using ScriptRunner to customize notifications since the built-in JSM notifications aren't customizable and missing so many key fields and information. It's a lot of overhead to reconstruct an email notification system, but until JSM has the ability to tailor the notifications out there, this is the route we'll need to take.

+1 still waiting this to being implemented.

This needs to be implemented.

Is there any update as this issue has been open since 2017

Definitely agree!

:+1

+1
need to put the customer company name in the subject of the agent notification email easily.

+1

+1.  For a specific project, we want to remove the content of issue updates while still getting notified of changes.  This is to ensure that sensitive information does not make its way out of Jira and into email systems.

+1

+1

+1

We need to put the customer company name in the subject of the agent notification email to easily.

+1

We created 1 project to house 7 different departments by making the request type the department names. We need a way to put the request type in the subject of the emails going to the agents so that we can create outlook rules to only see the ones for our specific departments, right now every department sees the new ticket and new comment emails which is very confusing.

This is a very important functionality as we would like to customize our own email templates.

Considering that the automation workaround is rather flexible, I wonder if it might be better if Atlassian simply removed the "old school" notifications methods and just gave the admins read-made automation templates to serve the purpose of all the old notification methods.  This would reduce confusion so that admins wouldn't be left wondering which is the best/most correct way of setting up notifications.

As part of the IT team is very important for us to make things work as simple and fast as possible. Having the option to see not only the user that is creating the ticket, but also their e-mail address is a huge help. As of now, we have to look for the user all the way to their profile under the Atlassian suite administrator, and doing it for every request gets tidious.

This functionality is very important to us. Because we have to stay between Jira and the mailbox.

This feature as soon as deployed will be of great use to our team.

This functionality is very important to us. Because we have to stay between Jira and the mailbox.

This feature as soon as deployed will be of great use to our team.

In our case we need to know how to incorporate, to the notification by email, the person in charge of the task when it is updated. Currently we only observe the person responsible for the task in the notification by email when we create it.

We consider that an observer of the task should see in the notification by email who is responsible when it is updated.

We hope your understanding and collaboration

Regards!

Agreed. This feature is a must have for our organisation as we need the email notifications to tell us when a customer has lodged an urgent/non-critical support ticket.

Customising issue variables will allow us to put issue descriptions and other related info to the ticket in a short email, giving the service desk team key information about the issue simply by looking at the email. This will help the team prioritise their work in the day without having to swap between their mailbox and Jira all the time.

I fully agree

We need this feature.

It's a problem that we can customize notifications for users, and not for the agents.

We have a smaller support organization. Much of our support usually begins with individuals assigned to various accounts (organizations). Being able to see additional metadata in some notifications to agents would be valuable. For example, a triage person seeing a support ticket was logged by "Joe" from organization "ABC" would help the triage person know who to assign the support case to. Having the basic flexibility to configure the content of the agent notifications similar to the way you control the content of the customer (external) notifications would be ideal. Thank you for considering!