nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Email Notification Issues

Bo Glenn

We are evaluating JSD Cloud for our organization. We will be using a paid plan but we are concerned about what we are seeing. We see the described use cases as bare minimum functionality.

We are currently experiencing email notification issue with organizations and agents. Here are the details:

Assumptions:

we are using default notification scheme that comes with JSD Cloud and have not made any changes
all members (organization and agents) have existing email addresses prior to sign up/account creation
test organization consists of two members (reporter (R) and second member (S))
support agent (A) is also an admin
R and S were switched to rule out issues with email servers/services

Use Case (steps to reproduce - shown in order of time sequence)

Use Case #1 -- all replies via email client

1) R sends email to Jira Service Cloud email ([domain].atlassian.net and issue is created

NOTE: A does not receive email indicating that issue has been created

2) R receives automation email and S receives notification email

3) S replies using email client, reply is added to Jira ticket, R receives email notification of reply

4) R replies using email client, reply is added to Jira ticket, S never receives email notification

Use Case #2 - replies via portal (continuation of Use Case # 1)

1) A replies via portal, R receives reply, S does not

2) S replies via portal, R receives reply, A receives reply

NOTE: this is the first time that A receives any email notification

3) R replies via portal, S does not receive reply, A receives reply

We require all members (A, R, S) to receive email notifications when applicable and do not understand why this is not working. We are seeking support to resolve issues between the two use cases. Thanks in advance for the support.

Accepted answers

Petter Gonçalves

Hello @Bo Glenn

Welcome to the Atlassian community!

Per your description, I understand you have not changed any details related to Agent or Customers notifications yet to achieve the scenario you are looking for. Is that correct?

Please, Allow me to provide some concepts and details about each topic you have so we can give you the instructions to achieve the scenario you need and confirm we are on the same page:

Use Case #1:

NOTE: A does not receive an email indicating that issue has been created

By default, the Issue Created notification is only sent if the agent is assigned or watching the issue. To configure your Agents to receive notifications when a new issue is created even if he is not assigned/watching to it, you must add them to the Issue Created notification under project settings > Notifications (Not customer notifications).

R replies using email client, the reply is added to Jira ticket, S never receives email notification

I suppose the user S is added as a request participant in the issues. Right?
To ensure your request participants receive a notification when the issue is commented, navigate to project settings > Customer Notifications > Click to edit in the Public Comment Added notification, and ensure the customers involved are configured to receive the notification.

Additionally, Check under Project settings > Customer permissions if it is configured in a way that would allow access to the issue by the request participants in the same organization.

Use Case #2:

A replies via portal, R receives reply, S does not

I Believe this behavior is caused by the same lack described in the last topic. Check if the Public Comment Added notification is being sent to the customer involved (Request participants) and the Customer permissions are properly configured.

NOTE: This is the first time that A receives any email notification

This reinforces the details provided in the first topic, where the Issue Created notification is not sent because the Agent does not match the conditions (Assignee or watcher) to receive the notification. Once The Agent is assigned or become a watcher in the issues, the notifications are received.

3) R replies via portal,S does not receive reply, A receives reply

Again, Check the steps provided before (Public Comment Added and Customer permissions) to ensure your request participants are configured to receive notifications.

To have more details about the steps provided, please check the documentation below:

Set up notifications for your customers and team

Let us know if you have any questions.

All comments

Petter Gonçalves

Hello @Bo Glenn

Welcome to the Atlassian community!

Per your description, I understand you have not changed any details related to Agent or Customers notifications yet to achieve the scenario you are looking for. Is that correct?

Please, Allow me to provide some concepts and details about each topic you have so we can give you the instructions to achieve the scenario you need and confirm we are on the same page:

Use Case #1:

NOTE: A does not receive an email indicating that issue has been created

R replies using email client, the reply is added to Jira ticket, S never receives email notification

Additionally, Check under Project settings > Customer permissions if it is configured in a way that would allow access to the issue by the request participants in the same organization.

Use Case #2:

A replies via portal, R receives reply, S does not

NOTE: This is the first time that A receives any email notification

3) R replies via portal,S does not receive reply, A receives reply

Again, Check the steps provided before (Public Comment Added and Customer permissions) to ensure your request participants are configured to receive notifications.

To have more details about the steps provided, please check the documentation below:

Set up notifications for your customers and team

Let us know if you have any questions.

Bo Glenn

Thanks for the response. My replies are shown with [BG].

[BG] Thanks for the suggestion on the Issue Created. I will look into that.

I suppose the user S is added as a request participant in the issues. Right?

[BG] No. S is just a member of the organization that I have assigned to the incident. I have not added any request participants. I am expecting/assuming that all members in the organization would be notified. Is this an incorrect assumption?

[BG] I have verified that Customer Involved is selected but as mentioned I do not have any request participants manually selected.

Petter Gonçalves

Hello @Bo Glenn

To be able to share an issue with a specific user, he must be added to the request participants field. The organization field only allows the customer that reported the issue to add the users of the same organization to the request participants field (If this is defined in the customer permission page), however, the request participants field is what defines which customers can directly access that request.

That being said, if the customer does not select anyone of their organization to share the request with, the request participants will remain blank and the request will not be shared with anyone.

Let us know if this information answers your question.

Bo Glenn

Thanks. I have been able to resolve most of our issues. However, I have now ran into something that I cannot resolve/understand.

I have done the following:

1) create a internal note using the @ notation which correctly emails all members referenced by @ name/label

2) one of the internal team members then replies via the email client to the internal note received

At this time Jira shows the email reply to the internal comment as a public comment and the customer receives an email containing what should be an internal only reply. Why is Jira doing this? Jira should know the email sent is about an internal comment and therefore all replies should also be kept internal.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-desk