Managing service desk notifications

When customers submit requests through the customer portal, they receive notifications to keep them informed about the progress of their requests. We call these service desk notifications.

JIRA platform notifications are different. When agents and admins work on issues inside of JIRA Service Desk, they receive notifications about an issue's activity through the JIRA platform. Admins can configure JIRA platform notifications through each project's notification scheme.

How different roles receive notifications

A service desk project sends notifications based on two schemes:

  1. One for your customer
  2. One for your licensed users (most likely your agents and admins)
Customers
When a customer submits a request they receive our default email notifications, as the issue reporter or participant.

For service desks that have incoming email and public sign-up, accounts are actually being set up in the backend. An email is sent to customers asking them to reset their passwords and verify their account details.

Service desk admins can disable these account verification emails, if necessary.

Customers in an organization receive notifications when other members of the organization share requests with the organization. They must opt in to notifications to see other activity on the request.
Approvers receive service desk notifications when a request transitions to a stage where their approval is needed. They must opt in to notifications to see other activity on the request.
All other customers receive notifications for all public activities on the requests they're involved in.
Customers can opt in or out of a requests' notifications in the customer portal or email. Reporters who opt out are only notified when the request is resolved.
Agents and admins

When agents and admins work on an issue, they receive email notifications as part of the project's JIRA notification scheme.

Agents don't receive notifications of their own changes when they act as a customer on issues with a set request type. 

Agents acting as a reporter, participant or approver on these issues are always treated as a customer, regardless of the settings in their project's JIRA notification scheme.

Agents who are part of an organization, will only receive a customer notification when a request is shared with that organization. If the agent is the assignee of the ticket, they won't receive any notifications from the project's JIRA notification scheme.

Account verification emails

When customers raise a request by email, the following events take place:

  • An account is created for the customer in the backend, so they can access the customer portal
  • A notification is sent to the customer, asking them to verify their email address and reset their password, so they can access the customer portal

This is confusing for customers of organizations running email-based service desks; being an email-based service, only the licensed users of the organization (agents and admins) would most likely be using the customer portal.

As Project Administrator, you can disable account verification emails, to avoid confusing your customers.

To disable account verification emails:

You need to be an administrator for your project to make the following changes.

  1. From your project's sidebar, select Project settings > Customer notifications.
  2. Under Account verification email, enable Do not send account verification emails.

Edit, disable, and customize notifications

To edit the recipients or message content of your service desk notifications:

  1. From your project's sidebar, select Project settings > Customer notifications.
  2. Select Edit next to the notification you wish to alter.

To disable a notification, untick the Enable checkbox while editing.

tip/resting Created with Sketch.

Pro tip: To create custom email triggers, go to Project setting > Automation and create a new custom rule. Set up your triggers and use the "send email" THEN action.

Choose recipients

Add at least one of the following to the To field:

Recipient options Details
Reporter (customer)

The reporter of the request.

This notification is sent even if the reporter has opted out of receiving notifications on the customer portal.

Customers involved

All customers involved on the request, including the reporter and request participants.

This notification is not sent to customers if they have turned off notifications for an individual request in the portal or a request's email thread.

Added participants The people who have been added as request participants.
Added organizations The people in an organization that the request has been shared with.
Approvers The people who need to approve or decline a request.
Exclude person who caused the action Prevents the person who triggered the rule from receiving a notification. For example, if a customer adds a comment to a request, you can choose to exclude them so they don't receive a notification about their own comment.

Include issue information using message variables

You can use variables to pull blocks of information from issues and insert them into your message. Select the Insert variable drop down menu to add valid variables for the notification you're customizing.

Name Format Description
Recipient name ${recipient.name} The full name of the person receiving the email.
Name of person who caused the action ${event.user.name} The full name of the person who triggered the notification, for example by adding a comment.
Issue summary ${issue.summary} The summary of the issue, or blank if there's none.
Issue description ${issue.description} The description of the issue, or blank if there's none.
Issue key ${issue.key} The issue key (for example, IT-123).
Issue reporter ${issue.reporter.name} The full name of the user that reported the issue.
Issue resolution ${issue.resolution} The resolution of the issue, for example "done".
Request URL ${request.url} The URL of the request in the customer portal.
Comment ${comment}

The comment added to the issue.

This is only available using the "Comment added" or "Comment edited" WHEN trigger.

Request status ${request.status} The customer-visible status of the request, as shown on the customer portal.
Portal name ${portal.name} The portal name, which can be edited on the Portal settings page.
Request details ${request.details}

The full details of a request.

This includes the creation date, request type, summary, and the same fields chosen in the request type settings.

Approval buttons ${approval.buttons} The Approve and Decline buttons to action requests from within the email.
tip/resting Created with Sketch.

Pro tip: Fast-track the time it takes approvers to action pending requests, by inserting Request details and Approval buttons to your approval notifications template, if they aren't there already. 

Support additional languages and translations

Provide translations and regional messages to your service desk's customers. To add or remove a language to your service desk project:

  1. Go to Project settings Customer notifications.
  2. Under Language support, select Manage languages.

The languages your service desk supports appear in the table. You can add any languages that your site supports.

We disable new languages by default. When you add a language, your service desk introduces translated notification messages and templates from our default style. Take your time customizing and adjusting these before you decide to enable a language.

If your customer prefers a language that isn't supported in your service desk, they receive notifications in the project's default language.

Translate customer notifications

When creating your message: 

  1. Select a language from the drop down.
  2. Add your translations into the content area, including any relevant variables. 

If you leave translations blank, your service desk sends notifications in your instance's default language.

Customize your subject line

Your service desk puts a default subject line on all customer notifications. To change your service desk notifications' subject line:

  1. Go to Project settings > Customer notifications.
  2. Select Edit templates.
  3. Under Subject, edit your subject line.

We require you to keep the issue key someplace in your subject line. This helps thread a request's notifications into a single email conversation.

Style notifications with HTML, CSS, and plain text templates

To change the look and feel of your email notifications:

  1. Go to Project settings > Customer notifications.
  2. Under Templates, select Edit templates.
  3. Adjust the HTML, CSS, and plain text styles as you like.

You can create different styles for different languages using the drop down. 

Include more information using template variables

Similar to the variables you can add to individual notification messages, use this set of variables to pull blocks of information and add it to your email template.

Name Format Description
Message content ${message.content} The content of your notifications. We require this variable. This variable includes batched messages.
Request location

${request.url}

The URL of the request.
Disable notifications location

${request.disable.notifications.url}

The URL to turn off notifications for the request. As a best practice, we recommend always including this link.
List of request viewers

${request.sharedwith}

The participants, approvers and customer organizations who can also view the request.
Help center name

${helpcenter.name}

The name of your site's help center, an entry point to all customer portals on your site.
JIRA Service Desk homepage ${atlassian.url} The URL of JIRA Service Desk's homepage.

Target additional default CSS classes

You can style more classes than appear in the default template.

Name Class Description
Reply marker .jsd-reply-marker The style of the reply marker. This series of dashes and hyphens is used to process comments when a customer replies to a notification.
Batched item container

.jsd-activity-item-content

The style of a division used to wrap individual messages added to a batched notification.
Batched message separator .jsd-activity-item-separator The style of a separator inserted when batches of messages are sent as a single notification.

Choose HTML or plain text

As a JIRA administrator, you can set the default email type for all notifications sent by you site. If the default type is set to HTML, dual-encoded notifications are sent, allowing your customers to then select the HTML or plain text view in their mail client. If your customers use a plain text mail client, you can change your default setting and apply it to new and existing customers.

  1. Choose  > System
  2. Scroll down to the User Interface section and choose Default User Preferences.
  3. Select Edit default values
  4. Change the Default outgoing email format to HTML or text and click Update.
    At this point, the email format you have selected will only be applied to new service desk customers. If you also want to override the email format chosen by existing service desk customers and agents:  
  5. Under Operations, select Apply
  6. Select Update to finish applying the email preference to all user accounts. 
Last modified on Apr 9, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.