Introduction

JEMHC gives you flexibility on whether to use any combination of inbound processing and outbound notifications, whatever fits your needs, but choices have impact regarding the monthly Capacity Plan.

JEMHC usage is the sum of inbound mail read and outbound mail sent in terms of MSG count and Data MB. If your MSG /Data usage exceeds your plan causing https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/3743416325 there are some things that can be done.

JEMHC Auditing

Become familiar with JEMHC Auditing, see https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/3743416325/Capacity+Plan+Fully+Consumed#Usage-Monitoringfor how to locate problem projects/issues/mail.

Minimize Maintenance Traffic

Maintenance traffic is mail that doesn’t result in an issue create/update. All maintenance traffic counts, you need to understand the cause and minimize it to get best use from your Capacity Plan. Left unsolved, out of control maintenance traffic can consume your plan, resulting in a blocked service, requiring DataPack purchases.

Inbound optimisation

Exclude high volume unwanted traffic in your mailbox

JEMHC counts all inbound mail in terms of MSG and Data and whilst there are ‘allowlist’ blocking features, this is to prevent ingress into your Jira instance it still counts against your Capacity Plan. JEMHC processing of such redundant emails can be avoided by implementing Rules in your Mailhost account based on sender/ subject/ size etc to exclude/ delete/ otherwise remove the message.

Outbound optimisation

Control of outbound notification is through JEMHC > Notifications > Notification Mappings, that can aggregate settings for a number of projects (or all).

Message Volume

Recipient Type is Bcc: for a reason

The JEMHC default notification method is Blind Carbon Copy (bcc:) that result in one email delivered to multiple recipients (grouped by ‘content’ uniqueness) excluding the recipient addresses from the received mail (for privacy reasons). Changing the delivery type here to to: causes one mail per recipient, if your issues have 10 recipients, that's 10x the MSG and Data volume.

Limiting notifications to just those containing comments

Check “Only Send Notifications When A Comment Is Present” for this.

Limit notifications to those matching a JQL expression

Set “JQL Whitelist” for this.

Audience

As a remote app the Jira Notification Scheme is unusable. If JEMHC is to be used for notifications, the Jira notification scheme should be disabled and/or Jira Service Management notification disabled to avoid duplicate notifications.

JEMHC can enable email-only interaction with your Jira instance if ‘non-jira’ (no account) user support is enabled (see the https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/30179405 for how). JEMHC Notifications need to select the audience, typically Email and Jira Users would be selected. If you want Jira itself to do all Jira notifications, that's fine, you can scope JEMHC to just handle Non-Jira (no account) users. NOTE that in some cases, access to Jira projects is denied to a given User, in such cases, where you have non-jira (no account) user support enabled, JEMHC can prove a best effort solution by storing the users email address in a custom field, in such cases, you will need to enable “Email” user support in the audience for them to get any notifications.

The “Email Custom fields” should contain only email addresses (eg user@domain.nnn) set/managed by JEMHC as referred above, they are CSV fields, ' ; ' is not a valid separator, use of “personal part” is not supported.

You can choose to enable various entities on the issue for notification (eg Reporter, Assignee etc), there is also support for User/Multi User Picker fields and even Group/Multi Group Picker fields. Combining these settings with to: Delivery Type can have a huge impact on plan usage if not managed carefully.

Inhibiting notifications through the template

JEMHC will render the TemplateSet for the issue notification for each recipient in scope, during that render it is possible for custom markup to drive the current notification (recipient) to be inhibited, see for more, and for how to work with the Webhook event.

Data Volume

There are some great features in JEMHC for including images/attachments in outbound notifications, however, these come at a cost in terms of your Capacity Plan.

The JEMHC Notification Mapping “Attachments” section enable per resource and cumulative resource limits to be set that apply to outbound mail:

Global Attachment Exclusion

JEMHC > Exclusions > Exclude attachment by content type, size and file name allows you to globally exclude files based on size, name (including extension) or even mime type.

Include Attachments

“include attachments” to enable attachments (and images) at all

“only below” is used to ensure no ‘large’ files get attached

“Not more than MB total” is used to ensure the cumulative size of mail sent does not grow unexpectedly, 25MB is a good limit for most mail hosts. Even if your mail host supports larger, think carefully about the usefulness of sending > 25MB+ by email. Where high data limits are set, compounding with Recipient Type and Audience there is scope to completely consume your Capacity Plan.

“Recent Attachment Window” limits how far back in time at the point of processing that attachments will be considered (via their creation timestamp) for inclusion in a notification. Making this too large can include attachments added by other users for other purposes, making it too small can exclude attachments that a user may add during a lengthy comment.

“Thumbnail Images” allows fullsize images to be also added (where the inline content uses a thumbnail). By including full size images, you increase Data usage.

“Inline Image Strategy” enables inlining of images that may be referred to in the comment, it can be turned off but then the comment may be harder to understand in context.