Email This Issue
πŸ“ˆ Marketplace❓ Support❀️ Feedback🏠 META-INF Apps
Email This Issue - for Jira Cloud
Email This Issue - for Jira Cloud
  • ⬇️Overview
  • Email This Issue - for Jira Cloud
  • Features
  • How Email This Issue Works
  • Secure the email channel with Email This Issue
  • Comparing Email This Issue and Jira Cloud
  • πŸ“€Outgoing Emails
    • Outgoing emails overview
    • Manual emails
      • Configuring manual emails
      • Sending manual emails
    • Email notification schemes and email notifications
    • Workflow post functions
    • Advanced email configuration
    • Customizing email templates
    • Canned Responses (default messages)
    • Scope evaluation
  • πŸ“₯Incoming Emails (Mail Handlers)
    • Incoming emails overview
  • Mail handlers - adding / editing
    • General handler settings
    • Filtering
    • Finding issues
    • Setting up rules and actions in the actions editor
      • Adding/editing actions
      • Adding recipients to Request Participants
      • Creating an issue
      • Updating an issue
      • Setting field values
      • Adding comments
      • Sending auto-reply emails
      • Executing workflow transitions
      • Creating a customer
      • Using split regexp
      • Conditions
      • Approve request
      • Decline request
    • Maintaining email chains
    • Mail Handler New UI
  • Global Sender Address Filters
  • Attachment Filters
    • Regular Attachment Handling Deprecation
  • πŸ€“Administration
    • Outgoing Mail Connections
    • Alerting via Webhooks
      • Webhooks
        • Configuring Slack to receive alerts via webhooks
        • Configuring OpsGenie to Receive alerts via webhooks
        • Configuring Microsoft Teams to receive alerts via webhooks
      • Webhook execution logs
    • Mail Queue
    • Email Audit Log
    • Permissions
    • Recipient Restrictions
    • Incoming Mail Connections
    • Email Security
    • Incoming Mail Queue
    • Incoming Mail Log
    • OAuth2 Credentials
      • Enabling OAuth2 Authorization in your Google Account
      • Enabling OAuth2 Authorization in your Microsoft 365 Account
      • Troubleshooting guides for Microsoft OAuth2 Connections
        • How to fix "BAD User is authenticated but not connected" error​
        • How to fix "401 Unauthorized" error
        • How to fix "key expires_in " error
        • How to fix "Need admin approval" error
  • ☁️Server to Cloud Migration
    • πŸ›«Server to Cloud - Automatic Migration tool
      • Preparing for the migration
      • Doing the migration
      • Finalizing the migration in Cloud
      • Migration with unsupported Jira versions causes errors
    • Server to Cloud - Manual migration guide for Email This Issue
  • ❓FAQ
    • No recipients error in outgoing emails
    • How-to add custom macro to email Template?
    • Why cannot I select custom event types in notification?
    • How to configure the Email This Issue addon user in Jira Cloud?
    • I get an error: Could not create request on behalf of the sender
    • Why is the Incoming Mail Queue size limited?
    • Outgoing mail not sent - Read timeout error
    • Access restriction icon is not appearing when adding internal attachments via Email this Issue
  • πŸŒͺ️General
    • Release Notes
    • API
      • API for Velocity Context Objects - 1.7
      • API for Velocity Context Objects
    • Addon Pages
      • Integrity Check
      • Feedback and Support
    • Security Advisories
      • Email This Issue Security Advisory September 28, 2020
    • Appendix
      • Supported Time Zones
    • Integration of Glass Documentation
Powered by GitBook
On this page
  • Notification to End Users
  • Notification to (System) Administrators

Was this helpful?

  1. Administration

Alerting via Webhooks

Alerting allows Email This Issue for Jira administrators (and in some respects, regular users, too) to get some feedback in the form of notification alerts in the event of run-time failure or misconfiguration of incoming mail connections, outgoing mail connections and mail handlers.

Alerts and notifications may be sent for various incidents.

Types incidents

Target audience of the alert

Type of feedback

Manual emails not sent

Users who sent the emails

Outgoing email status is indicated in the Audit Log (admin-only visibility), as well as on the Emails tab of the issue screen (also visible by any logged-in user)

Outgoing Mail Connections not working / Outgoing Emails end up in Error Queue

Outgoing Emails end up in the Outgoing Error Queue. tthis may be caused either by errors at the infrastructure level (connection error) or by errors in the app, like templates that prevent the generation of emails

Administrators

Webhook alert

Incoming Mail Connections not working

Emails cannot be downloaded

Administrators

Webhook alert

Mail Handlers fail to process emails

Incoming emails end up in the Incoming Mail Error Queue

Administrators

Webhook alert

Mail Handlers filter out emails

Incoming emails end up in the Incoming Mail Skipped Queue

Administrators

Webhook alert

Notification to End Users

In Email This Issue for Jira, emails are queued and delivered in batch. In the past, if an email could not be delivered successfully, end-users had no feedback on the failure (except for the admin, who could check the Error Queue manually). Now, by displaying the status of the outgoing emails on the Emails tab of the Jira issue, regular users can also monitor the dispatch process and make sure if their message was sent in fact. If not, they can contact their Jira administrator to fix the issue and send the affected message(s) again via the β€œResend” operation afterwards.

Status values include:

  • Queued : if the audit log entry for an outgoing email is created. This status is available in the Server and DC versions.

  • successful : if the email was correctly sent via the corresponding Outgoing Connection

  • failed : if the email could not be sent via the corresponding Outgoing Connection and resulted in the Error Queue

Notification to (System) Administrators

The notification can take place in various forms and on different channels, however, technically speaking, they are all kind of HTTPS requests sent to a third-party service (some web - mostly REST - API calls), this is why the are called webhooks. Email This Issue provides you built-in integrations (i.e. pre-filled templates) with two popular service providers, by default:

  • OpsGenie for advanced incident management

  • Slack for prompt and instant visibility across the whole team

Besides them, the user may configure any other (custom) service of their choice.

The webhook alert may include several additional information about the source event (e.g. to help in the identification of the issue and creating a more particular ticket for the incident or to send a more customized, formatted message with sufficient details). These details can be referenced and inserted into a highly customizable, JSON-based template via pre-defined Velocity variables.

The administrator may create and configure various webhooks for a variety of incidents that will fire alerts individually, if their trigger criteria are met. Each webhook can be temporarily enabled or disabled. In addition, any newly created webhook can be tested with self-specified test data to double-check the structure and content of the resulting alert.

The administrator has the choice to suppress subsequent identical incidents, preventing the flooding/spamming of the channel used for alerting (without delivering any added value). By applying this setting, if the same type of issue prevails for a longer time (i.e. a series of events have the same root cause), the incident will only be fired after a one-hour long time-window again.

Each time an event is fired that is matching an active webhook configuration, the webhook is being executed, i.e. the notification alert is being constructed based on the specified template and then getting sent out. A particular event may fire multiple webhooks, so it is possible to send notifications about the same incident via different channels (e.g. both into OpsGenie and Slack at the same time).

Administrators are allowed to inspect the logs generated upon each webhook execution. If there is some issue with sending out the notifications, the administrator can double-check the configuration of the respective webhook and do the necessary fixes accordingly. Webhook executions logs are listed based on their time of execution, in descending order. In addition, they are automatically deleted after 90 days.

PreviousOutgoing Mail ConnectionsNextWebhooks

Last updated 3 years ago

Was this helpful?

πŸ€“