The Email notification mapping is in charge of sending email messages from Issue events through a select outbound mail server. Within these Notification mappings you select the users and email address Custom Fields that should be notified.
A Outbound Mail Server would need to be configured within JEMHC > Messaging > Message Outbounds in order to configure a Email Notification Mapping. See: Message Outbounds (Email) |
Go to JEMH Cloud > Notifications > Email > Create
Select the nominated projects, Mail Outbound to use, the templates to use and the users to notify e.g. Notify reporter. (More info about the options below)
On Submit, you should see the new SMS mapping
Within the Notification Mapping configuration there are many different options that can be selected to customise how the Email Notifications are sent and who they are sent to. This section will cover each of these options.
The Name of the Notification Mapping.
Defines whether the Notification Mapping can be used.
This is the Outbound mail server that should be used to send the notification
This defines the format that the email notification should use. The options are Text and HTML.
The Template that is used to render Issue Created Notifications
The Template that is used to render Issue Updated Notifications
The Template that is used to render Issue Deleted Notifications
This means that a comment must be present within the event for the notification to be sent. This means that if the event is only a field value change then a notification will not be sent.
This defines the Projects that the Notification Mapping will send notifications for. This can be either be a select few Projects or for all Projects.
This defines the header that should be used when sending the notification. The current options are To and Bcc. If To is selected then you will see a impact in the plan usage as each message will be sent individually. Recommended to use Bcc as multiple recipients can be notified with one message.
This allows you to customise when the notifications can be sent. As only issues that match this JQL expression will receive notifications.
This is the Email address that is used within the From header for the notification. Your mailbox must be allowed to send emails as the resolved address. Leave it blank to use the Message Outbound's sender email address.
This will extract an address from a Custom Field and then use this address within the From header of the email. This value must use one of the following formats to be used: Sender Name <sender@example.com>
or sender@example.com
. Your mailbox must be allowed to send emails as the resolved address. This overrides Sender Email Address and Sender Personal.
This is a name that will be used as the personal sender for these notifications. Leave blank to use your email server’s default.
This will use the full name of the user that performed the action as the sender personal. This overrides Sender Email Address Custom Field and Sender Personal.
This will set the Reply-To header to this address. If not set, mail clients use the from address when a user replies to the email.
If this custom field contains a value that has a format of Replies Name <replies@example.com>
or replies@example.com
then it will be used for the Reply-To
header of the notification.
This will send a notification to the user that performed the action.
This allows you to choose who should receive notifications. The options are:
Email Users
Jira Users
Email and Jira Users
If Email Users or Email and Jira Users is selected then Email Address Custom Fields configuration will appear.
This is where you define the Custom Fields that contain Email addresses that should be notified. Typically the same Custom Fields as the ones selected within Profile > Project Mapping > Email Only Users.
This will send notifications to the Reporter of the issue.
This will send notifications to the Assignee of the issue.
This will send notifications to the Watchers on the issue.
This will send notifications to all of the Request Participants found on the issue.
This will send the notifications to the user that performs the change on the issue.
This will send the notification to the Project Lead. This is defined within Project > Project Settings > Details > Project Lead.
This will send the notifications to the Component Lead when a component has been selected on the issue. This is defined within Project > Project Settings > Component.
This will send the notifications to all of the members of the request organization.
This will send the notifications to the request approvers.
Sends the notifications to all users found within the selected Custom Fields.
This is a static list of users that should that receive notifications.
Sends the notifications to all of the groups that are found within selected Custom Fields
Static list of groups that should be notified
This allows you to create a Velocity Script that will add email address, user or groups dynamically. This allows recipients to be added conditionally.
For more info see: Add recipients by Velocity script
Enter a valid email address to be used as a BCC participant in all outgoing notifications.
This controls the size of attachments should be sent with the notifications. Here you are able to set:
The maximum size of each attachments that should be included in the notification. If exceeded then that one attachment will not be attached within the email.
The maximum total size of all the attachments combined. If exceeded then all of the attachments will not be attached within the email.
A message will be displayed within the Report for this event when attachments exceed these limits. |
This will only add attachments that have been added to the issue within this specified time frame (e.g. 5 minutes) and if they have not already been sent. If they were added to the issue before the specified time frame or were sent in a previous email then they will not be included within this email notification.
This allows you to select the types of templates that can include attachments. If the template is not one of these specified types then the attachments will not be attached.
Current types are Issue Created, Issue Updated and Issue Deleted. Leave bank to include all template types.
Defines the strategy to use when adding thumbnail images to email. Current options are:
Show Fullscreen Image
Show Thumbnail Image
Show Thumbnail Image and Attach Fullscreen image
This defines when images should be inlined within the notification. Current options are:
Inline All Images - Inlines all Images that are found
Inline Secured Image Only - Only images that need authentication such as issue attachments are attached inline.
Don’t Inline Images - External images are not inlined within the email.
This is where you select the Static Resources that should be sent within all of the notifications.
If the Static Resource is not scoped for that Project then it will not be included. A message will be displayed within the Event Report. For more info about static resources see: Static Resources |
Mail server clients may require different headers in order to group emails together (JEMHCloud email to be displayed below the original email that created the issue). For example Gmail requires the incoming email to include the original Message ID as a Reference and the original subject to stay the same. The following options allow you to tune those headers.
Adds the Message-ID of the email that created the issue to the References header of outgoing emails.
This will use the subject of the original email that created the issue instead of the subject resolved from the template.
Note: system subject templates include the created issue key in the subject. not having the issue key in the subject will make JEMHC less resilient when associating a reply email to an existing issue |
Customer Satisfaction Feedback allows you to collect feedback on resolved requests.
When enabled, a star-rating form will be added to notification emails. Upon clicking a star, the rating will be recorded in the request and the user will be redirected to the feedback form where an optional comment can be added.
For more info see: Collect customer satisfaction feedback
Jira Service Management allows teams to set up approval steps in request workflows. For example, a manager may need to approve a new computer request before purchase. JEMH Cloud can integrate with request approvals by adding Approve and Decline buttons in the notifications it sends.
For more info see: Approving requests via email
By adding mail headers to notifications, you can potentially enable mail clients to filter more effectively. Selected fields will be populated in headers with the format X-JEMHC-DATA-FIELDID or X-JEMHC-DATA-FIELDNAME=value1,value2,value3.
This defines the strategy used when naming the Header within the email. Current options are:
Use Field Id - e.g. X-JEMHC-DATA-CUSTOMFIELD_XXXXX
Use Field Name - e.g. X-JEMHC-DATA-A_CUSTOM_CHECKBOX
These headers are only added when the notification is sent to a Jira User.
These headers are only added when the notification is sent to a Email User.