Connecting a Microsoft 365 shared mailbox to Jira Service Management Cloud

Why the obvious route does not exist

JSM Cloud connects a Microsoft mailbox through an interactive Microsoft sign-in. Someone signs in during setup, and JSM keeps polling the mailbox with the token it was given. There is no option to register an application in Microsoft Entra ID and hand JSM a client ID and secret or certificate, the way you would for any other integration that reads a mailbox without a person attached. Atlassian tracks that request as JSDCLOUD-14422 (78 votes, open since July 2024) and JSDCLOUD-13197 (35 votes, open since October 2023). Both sit at "Gathering Interest", which is not a commitment to build it.

So every working route either gives JSM a sign-in that can reach the mailbox, or keeps JSM out of your tenant altogether and moves the mail instead.

Route 1: redirect the mailbox to the project's own address

Every service project in JSM Cloud comes with an Atlassian-hosted email address of its own. Leave the shared mailbox unconnected and let Exchange pass the mail on: a mail flow rule in the Exchange admin center that redirects messages arriving at support@yourcompany.com to the project's Atlassian address. Nothing from your tenant is stored in Jira, no account gets a password it should not have, and your Microsoft admin stays in control.

Three things to get right:

• Redirect, not forward. In Exchange, a redirect passes the message on with the original sender intact, so the customer becomes the reporter of the request. A forward makes the mailbox the sender, and then every request is reported by support@ instead of the customer. That failure and its side effects are covered in our forwarding guide. Test it with one message and check who the reporter is before you switch the desk over.
• Outbound forwarding policy. Exchange Online's outbound spam policy restricts automatic forwarding to external addresses, and the Atlassian address is external to your tenant. If the rule looks right and nothing arrives, check that policy first; it is the usual reason, and your Microsoft admin may have to allow it for this mailbox.
• Failures are silent on the Jira side. When the rule stops working, JSM simply receives nothing, and there is no error to see in Jira. Send yourself a test request on a schedule, or watch the mailbox for mail that is not being picked up.

Replies from agents go out through the project's email settings, not through your Microsoft tenant. Atlassian's page on managing the reply-to address for a service project covers what customers will see as the sender.

Route 2: sign in with the shared mailbox's own account

A shared mailbox in Microsoft 365 has an account behind it; sign-in is disabled and it has no password by default. Community reports say the Microsoft sign-in in JSM completes if your admin enables sign-in on that account, sets a password and keeps IMAP enabled on the mailbox. One admin reported that receiving worked but that agent replies still went out from the default Atlassian address, which that thread never resolved.

What you give up: a mailbox that was deliberately created without a password now has one, and a sign-in-enabled account that your MFA and Conditional Access policies apply to. If your tenant requires compliant devices, that account needs an exclusion, because JSM polls from Atlassian's cloud, not from a laptop. When the password is rotated, the channel stops and someone has to reconnect it by hand. Some admins reject this route for exactly these reasons; the question that prompted this page was one of them.

If the sign-in ends in "Admin approval required", that is your tenant's user-consent policy, not Jira. A Global Administrator can grant consent for the Atlassian app, do the connect step themselves, or turn on the admin consent request workflow in Entra so the request can be approved.

Route 3: a licensed service mailbox

The cleanest version of Route 2 is not a shared mailbox at all: a normal, licensed user mailbox that exists only for JSM. IMAP on, its own credentials, excluded from the device-compliance policy, password rotation on a calendar with the reconnect step next to it. It costs a Microsoft license, which is the one thing Route 1 avoids, and it behaves like what it is: a service account. If you need the branded address on the outside and the mailbox on the inside, give the service mailbox the address, or alias it.

What the email channel gives you, and what it does not

Whichever route you pick, an email becomes a request with a summary, a description and the request type you set for the channel. It does not fill in forms or extra fields; for that you need the portal or an automation afterwards. Attachments on the email become attachments on the request. Emails that customers forward as an attachment, which is what phishing-report buttons and "see the thread below" habits produce, arrive as .eml or .msg files on the request, and JSM shows those as downloads only. If that is part of your desk's day, read the attachments checklist before customers start reporting that "the attachment is missing".

Reading the attached email on the request

Full disclosure: Dortus makes an app for that last problem. MailView shows .eml and .msg files on the request in the agent view, with scripts, forms and remote images removed, and adds a plain-English check of the email itself: SPF, DKIM and DMARC results from the email's headers; sender and link domains with lookalike letters from other alphabets or with accents (a typo in plain letters, such as paypa1.com, is not caught); and links whose visible text names one domain while the link goes to another. It only reads attachments: no copies, no storage, no external services. It does not touch the email channel; the mailbox routes on this page work exactly the same with or without it.

Short answers

Can JSM Cloud use an Entra app registration (client ID and secret) for a shared mailbox? Not today. Vote on JSDCLOUD-14422 if you need it; the alternatives are above.

Does the shared mailbox need a license? For Route 1, no: the mailbox stays as it is and Exchange moves the mail. For Route 2, your Microsoft admin decides what enabling sign-in on that account requires in your tenant; admins in the Community threads assigned the cheapest license and a password, which is Route 3 in all but name.

Will the customer still be the reporter? With a redirect, yes. With a forward, no. Check it with one test message.

How do I know the channel is still working? You do not, unless you test it. JSM shows nothing when nothing arrives. A scheduled test request is the cheapest monitor there is.

Questions

Spotted something wrong on this page, or a route we missed? Email support@dortus.com.