Jira Service Management not creating requests from email: a checklist

Start with the email log

Every email Jira Service Management fetches gets a line in the processing log, with a status: New request, New comment, Failed or Rejected. For Failed and Rejected, the Details column says why (Atlassian: About email logs in Jira Service Management). As a project admin, go to Channels & self service, then Email, select View logs for the account and choose Processing log. You can search by sender, subject or work item key, and download the raw message as an .eml file (Atlassian: View the email processing and connectivity logs).

For a connected mailbox of your own there is also a connectivity log: the result of each attempt to pull mail, roughly every 60 seconds. Atlassian shows it for company-managed spaces only. If the email is not in the processing log at all, it never reached Jira Service Management: start with steps 1 to 3.

1. Was it sent to the right address?

Email to the site's general address, jira@yoursite.atlassian.net, does not create or update requests. Customers need the address of the service space, which you find under Channels & self service, then Email. When a reply goes missing, look at the address the customer actually replied to: some email clients reply to the From address and ignore Reply-To (Atlassian: Troubleshoot email processing issues in Jira Service Management Cloud).

2. Is email turned on for the space?

Atlassian's troubleshooting article lists a turned-off email channel as a cause: replies to notifications then cannot be processed into comments. Turn email support on under Channels & self service, then Email (same Atlassian article).

3. Can Jira Service Management still read the mailbox?

This applies when you connected your own Microsoft, Google or other mailbox.

• Only unread mail in the inbox. Jira Service Management looks at messages in the inbox that are unread and arrived after the mailbox was linked, and marks them read once processed. If another mail client, a mailbox rule or another app opens or moves a message first, Jira Service Management never sees it. To retry a message, move it back to the inbox and mark it unread (Atlassian: Email process for POP, IMAP, cloud, and other email types).
• The connection itself. Microsoft and Google mailboxes connect with OAuth. "Rate Limited" or access-token errors in the connectivity log usually point to a permission or grant problem, and the usual fix is to remove the account under Channels & self service, then Email, and connect it again. For Microsoft 365, Atlassian notes that the person connecting needs Full Access to the mailbox, and the mailbox a valid license (Atlassian: Resolve Email Request Failures due to Rate Limit in JSM Cloud).
• Reconnect at a quiet moment. Email that arrives while the account is being reconnected is not processed (Atlassian: Switch your Microsoft and Google email accounts to OAuth). Atlassian also says shared mailboxes are not fully supported with OAuth and suggests a dedicated account.

4. Was the sender allowed to raise a request?

• No account, no request. If your customer access settings do not let customers create accounts, an email from an unknown sender is rejected; the log shows a self-signup error. Either allow account creation or add the customer yourself (Atlassian: Fix "self-signup disabled" error in Jira Service Management emails, What are customer permission settings for email requests?).
• Domain restrictions. If account creation is limited to certain domains, an email from another domain is rejected with "Email doesn't belong to domains allowed in customer access settings" (Atlassian: Resolving Domain Restriction Issues in JSM Cloud Email).
• Condition Pending. A first-time internal sender may need to verify a new Atlassian account before the request is processed; until then the log says Condition Pending (Atlassian: "Condition Pending" status in Jira Service Management Cloud email requests).

5. Was it filtered out?

A Rejected line means a filter caught the email. Reasons in the log include auto-replies, email sent from Jira itself, a potential mail loop and a sender on your blocklist (Atlassian: About email logs).

• Blocklist. Whole domains or single addresses, exact match only: example.com does not cover mail.example.com. Atlassian's page on the blocklist says: "This page applies to company-managed spaces only." (Atlassian: Manage your blocklist).
• Allowlist. Domains only. Mail from an allowlisted domain is not filtered, except that DMARC overrides the allowlist: an email that fails the DMARC check is still blocked (Atlassian: Manage domains on your allowlist, Manage DMARC authentication for incoming emails).

6. Can the request type take an email?

An email fills exactly two fields: the subject becomes the Summary and the body the Description. If the request type linked to the email address has any other required field, no request is created. Keep Summary and Description visible and make every other field optional (Atlassian: Choose suitable request type for connected email accounts). A workflow validator on the Create transition that demands a value for a custom field blocks email requests in the same way (Atlassian: Emailed requests are not created with an error in the logs indicating that a custom field is not correctly filled in).

7. Was the email empty?

By default the Description is required, so an email with an empty body does not become a request, and the customer is not told. You can make the Description optional on the request type for email. Atlassian points out the trade-off: the requirement also keeps spam from creating empty requests (Atlassian: How to Create Service Management Issues without an Email Body).

8. Get told next time

Jira Service Management can send an email when an email request fails: under Channels & self service, then Email, edit the address and choose all project admins, one email address, or no one. It does not cover everything. Emails rejected by a filter, emails over 25 MB and emails rejected by permission or access settings send no notice, so the processing log stays the place to look (Atlassian: Receive email notifications for failed email requests). Atlassian lists it for company-managed spaces.

What this checklist does not solve

• Email that never reaches your mailbox. Spam filtering at your email provider, routing or forwarding rules happen before Jira Service Management. Its logs cannot see them; your mail administrator can trace the message.
• Replies that become new requests instead of comments on the existing one. That is a different problem, not covered here.
• Jira Service Management Data Center. This page is about Cloud. Data Center has its own mail handler and settings.
• An incident on Atlassian's side. Check Atlassian's status page before you change settings.
• What arrived. When the request is created but its attachment is missing or mangled, see email request attachments missing in JSM.

When the request is a forwarded email

Customers often forward a suspicious or important email as an attachment. The request is created, but Jira Cloud shows the attached .eml as raw text and a .msg as code; see forwarding emails into Jira Service Management. Full disclosure: Dortus makes MailView, which shows forwarded .msg and .eml attachments as the email on the request, in Jira and in the Jira Service Management agent view. It does not help with any of the eight steps above: it only reads emails that are already attached.

Short answers

Where do I see why an email did not become a request? In the processing log: Channels & self service, Email, View logs, Processing log (project admin).

Why does Jira Service Management ignore emails that are in the mailbox? It only reads unread messages in the inbox that arrived after the mailbox was linked. Anything another client opened or moved is skipped.

Can I get an alert when an email request fails? Yes, for failed requests in company-managed spaces. Filtered and rejected emails send no alert.

Questions

Found a cause that is not on this list? Email support@dortus.com.