nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Connecting to a shared mailbox from JSM Cloud

Kevin

A collegue of mine is trying to connect JSM Cloud to a shared mailbox situating in Exchange Online. He wants to connect using IMAP4 and username/password. As general practice, a shared mailbox is disabled for logging on to.

It's common practice to use an app registation and permissions to read the mailbox (using IMAP4 or better, GraphAPI access).

I cannot find any applicable manual to configure this. Any help on this?
Is this a supported configuration by JSM Cloud?

Accepted answers

Mihai_LeanZero

The KB linked above is Data Center Only. It says so in the notice at the top.

For Cloud I'd check JSDCLOUD-14422 on Atlassian's tracker first, it reads "JSM does not support adding a shared mailbox using an OAuth token issued for a different user who has delegated access to a shared mailbox". Still gathering interest.

Comments there say it used to work, one as late as an early 2025 migration. Not tested on a live tenant.

Kevin, your ask is JSDCLOUD-13197. Also a feature request, so probably no app registration route today.

https://jira.atlassian.com/browse/JSDCLOUD-14422
https://jira.atlassian.com/browse/JSDCLOUD-13197

If it ends up as a redirect, keep the shared address without an account on the jira site. Atlassian's mail loop KB is about forwarding rules, but that account is the reason it gives for the notifications looping.

All comments

Matthew Sinclair

Forgive my ignorance - but what is the ultimate goal of configuring a shared mailbox in this context? That will help sort out where/what/how.

Kevin

Let's say i have servicedesk mailbox. He want's to create a ticket in JSM for every message received in the mailbox, or i.e. moved to a monitored folder.

I am not taking part in any form in the project, but i am asked to provide mailbox connectivity.

Matthew Sinclair

Assuming you are referring to JSM's built in Email Channel - you may find this useful → https://support.atlassian.com/customer-service-management/docs/set-up-email/ (Yes it says CSM - but it applies to JSM as well)

Also be advised - Email Channels are VERY limited in ticket flexibility.

You only get 2 Fields - the Subject (Summary) and the Body (Description) and the request type you designate.

No Forms - no additional information - you may have to do some work on the swing back.

Josh

Hi @Kevin , yes, a shared Exchange Online mailbox works, and you don't need to enable sign-in on it or create your own app registration. The piece that's easy to miss is who authorizes it.

In the service space, go to Space settings > Channels & self service > Email > add an email address, and choose the Microsoft option. This connects with OAuth through Atlassian's app, not a stored username and password.
Sign in with a real user account that has Full Access delegation on the shared mailbox, and enter the shared mailbox's address. In Exchange admin: Recipients > Shared > edit the mailbox > Mail delegation > Full Access, add that user.
Make sure IMAP is enabled on the shared mailbox.

If the authorizing user lacks Full Access, authorization fails with a confusing error. Atlassian has a KB on exactly that: https://support.atlassian.com/jira/kb/jira-mail-handler-and-service-management-mail-handler-cannot-be-configured-using-oauth-20-due-to-incorrect-mailbox-permission/

Use a service account rather than a person for step 2, so the connection doesn't break when someone leaves. Also note that Atlassian's docs say shared mailboxes via OAuth have some impersonation limits and recommend a dedicated mailbox where possible. So if you ever have the choice, a licensed servicedesk@ mailbox is the least fragile option.

Kevin

Thank you for the detailed attribution! Much appreciated!

The only thing is, thats exactly what i am trying to avoid, to create an account for a shared mailbox that has logon permissions. What's any different than enabling the shared mailbox for login? Not needing a mailbox license (free in our case) is the only thing i can think about.

Or don't i get your full message? In your first line you say "not a stored username and password" and in step 2 you sign in with an account.

Atlassian should move to an app registration using proper GraphAPI permissions and connecting using a appid/client secret key or certificate. That's a more proper configuration for use cases like this.

Matthew Sinclair

Not sure if you are aware but you technically don't need a mailbox of any kind to take tickets in.

All JSM spaces come with a email channel where Atlassian provides an "inbox" that you can use.

App Sync

Hi Kevin,

To your actual question: as far as I know, JSM's Microsoft connection only supports the delegated sign-in Josh described. There's no option to bring your own app registration with app-only Graph permissions, so an account with mailbox access has to authorize it.

If the goal is to avoid that entirely, don't connect the mailbox to Jira at all. Every JSM space already has an Atlassian-hosted address, something like support@yoursite.atlassian.net under Channels & self service > Email, as Matthew mentioned. Then let Exchange push the mail there:

Create a mail flow rule: when a message is sent to the shared mailbox, redirect it (or Bcc it) to the Atlassian address. Use redirect rather than forward, so the original sender becomes the reporter. Forwarded mail arrives looking like the shared mailbox sent it.
Microsoft blocks automatic forwarding to external domains by default in most tenants. If the redirect bounces with 550 5.7.520, create an outbound spam policy scoped to just that shared mailbox with automatic forwarding set to On, then confirm with a message trace.

That way nothing in Jira holds access to your tenant, and the shared mailbox stays sign-in disabled.

The trade-off: Atlassian's alerts for failed email requests only see mail that reaches Jira. If someone later edits that rule or a policy starts blocking it, mail just stops arriving, and Jira has nothing to report. If you monitor it, send your test to the shared mailbox address rather than the Atlassian one, so the test travels the same path your customers' mail does.

Disclosure, since it's relevant: We built MailWatch ( https://marketplace.atlassian.com/apps/1828859970/mailwatch-for-jira-service-management ), which runs that kind of test on a schedule and alerts you outside Jira email if it stops completing. It's free on the Marketplace. A scheduled test from your own monitoring works just as well.

Mihai_LeanZero

The KB linked above is Data Center Only. It says so in the notice at the top.

Comments there say it used to work, one as late as an early 2025 migration. Not tested on a live tenant.

Kevin, your ask is JSDCLOUD-13197. Also a feature request, so probably no app registration route today.

https://jira.atlassian.com/browse/JSDCLOUD-14422
https://jira.atlassian.com/browse/JSDCLOUD-13197

Kevin

Thank you all. It seems i have to enable the account at the end. To bad Atlassion hasn't made this possible as it is common practice for years now.

How to upvote the feature request?

Mihai_LeanZero

Open https://jira.atlassian.com/browse/JSDCLOUD-13197, log in top right. Same Atlassian account as here. Vote is in the People panel on the right, 35 votes so far. Hit Watch as well. Status changes on these Gathering Interest ones are slow, but the email tells you when it moves.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software-cloud

jira-cloud

jira-service-management