Hello Atlassian Support, We are trying to configure the native email channel in Jira Service Management Cloud using a standard Microsoft 365 mailbox (not a shared mailbox). During the Microsoft authentication process, the connection fails with an "Admin approval required" message. The Microsoft account can authenticate successfully, but the application permissions requested by Atlassian require tenant administrator consent. Could you please clarify: * Which Microsoft Entra ID (Azure AD) permissions are required by the Jira Service Management email integration? * Are there any known limitations or additional configuration steps when connecting a standard Microsoft 365 mailbox to the native JSM mail handler? * Is there documentation available that describes the required consent process and permissions in detail? Environment: * Jira Service Management Cloud * Microsoft 365 mailbox (standard user mailbox, not shared) * Native JSM email channel configuration * Error received: "Admin approval required" during Microsoft sign-in If needed, we can provide screenshots of the error and additional details about our Microsoft tenant configuration. Thank you for your assistance. Best regards, Armand Balla

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; } } }

Unable to connect Microsoft 365 mailbox to Jira Service Management – Admin Approval Required

Area Sistemi

Hello Atlassian Support,

We are trying to configure the native email channel in Jira Service Management Cloud using a standard Microsoft 365 mailbox (not a shared mailbox).

During the Microsoft authentication process, the connection fails with an "Admin approval required" message. The Microsoft account can authenticate successfully, but the application permissions requested by Atlassian require tenant administrator consent.

Could you please clarify:

Which Microsoft Entra ID (Azure AD) permissions are required by the Jira Service Management email integration?
Are there any known limitations or additional configuration steps when connecting a standard Microsoft 365 mailbox to the native JSM mail handler?
Is there documentation available that describes the required consent process and permissions in detail?

Environment:

Jira Service Management Cloud
Microsoft 365 mailbox (standard user mailbox, not shared)
Native JSM email channel configuration
Error received: "Admin approval required" during Microsoft sign-in

If needed, we can provide screenshots of the error and additional details about our Microsoft tenant configuration.

Thank you for your assistance.

Best regards,
Armand Balla

Accepted answers

Gabriela - LeanZero

Not today, going by anything Atlassian documents. Every documented way of attaching a Microsoft mailbox on Cloud runs through an interactive sign-in, and the tell is what happens when the wrong person does it. Their KB on that admin approval error warns that authenticating with an Azure AD admin account adds the admin account as the mail handler instead of the mailbox you wanted. That only happens where a signed-in identity is the thing being connected. Being straight though, that's me reading behaviour, Atlassian doesn't publish a line saying app-only is unsupported.

Nothing public on planned. Two open requests match your ask almost word for word, JSDCLOUD-13197 for OAuth without a personalized account and JSDCLOUD-14422 for a shared mailbox with a token issued for a different user, 71 votes on that one. Both sit at Gathering Interest, which isn't a commitment.

It's a genuine Cloud gap and worth putting to support in those terms. Data Center has a client credentials path on the Graph mail channel and Cloud doesn't.

One to plan around regardless: rotating the password on whichever account you connect drops the channel, and someone has to reconnect it by hand.

All comments

Marc -Devoteam-

Hi @Area Sistemi

Welcome to the community.

See this Atlassian KB, this will provide you with all details an necessary links to Microsoft documentation.

user-gets-an-error-jira-cloud-atlassian-needs-permission-to-access-resources-in-your-organisation-when-setting-an-office-365-account-as-an-incoming-mail-server

But you in Azure, you will need to have a Global Administrator or a Privileged Administrator to perform the changes.

Gabriela - LeanZero

Good news, in a way: that "admin approval required" screen isn't coming from Jira at all - it's Microsoft's, which means the fix lives on the Microsoft 365 / Entra side and not in JSM.

Here's what's actually happening. When you add the mailbox, JSM kicks off an OAuth consent with Microsoft so it can read that inbox. Your Entra tenant is set up so that regular users can't consent to third-party apps on their own, so instead of letting it through, Microsoft stops it with "needs admin approval." Your JSM config is fine - you've just run into the tenant's app-consent policy.

Three ways through it, depending on how your M365 admins prefer to run things:

The simplest is to have a Microsoft 365 / Entra global admin do the connect step, or grant admin consent to the Atlassian app. Admins aren't subject to that block, so the consent goes straight through and the channel finishes connecting.

If they'd rather not do the connect themselves, they can switch on the admin consent workflow in Entra (Enterprise applications > Consent and permissions > Admin consent settings > "Users can request admin consent to apps they are unable to consent to" = Yes). After that, when you hit the screen you can submit a request and an admin approves it, instead of being dead-ended.

The third option is to relax user consent so users can approve apps themselves, but that's the broadest change and most orgs deliberately keep it locked down, so the first two tend to be the sensible route.

Whichever they pick, it's an Entra setting owned by a Microsoft admin, so that's the person to pull in - nothing more to change on the Jira side.

Area Sistemi

Hello,

We are unable to determine from the documentation how this scenario should be configured.

We need to configure a JSM incoming mail channel using a standard Exchange Online service mailbox (not a Shared Mailbox).

Can a regular Exchange Online user mailbox complete the OAuth authentication flow directly and be used as the authenticating identity for a JSM incoming mail channel?

If so, could you please provide the recommended configuration and clarify any requirements or limitations when Microsoft Entra ID Conditional Access policies are enforced?

Area Sistemi

Sorry, additionally, I would like to provide the following information:

In our organization, users can authenticate only from Intune-compliant devices through Microsoft Entra ID Conditional Access policies.

Gabriela - LeanZero

Hi @Area Sistemi. Yes — a standard Exchange Online user mailbox works and is actually what Atlassian recommends over a shared mailbox, because OAuth authenticates directly as that mailbox rather than impersonating it. Enable IMAP on the mailbox in Exchange Online, then connect using its own credentials; that mailbox address is the authenticating identity, nothing else to map.

The Conditional Access requirement is the real blocker. JSM polls the mailbox from Atlassian's cloud using the stored refresh token, not from a managed device, so a policy requiring an Intune-compliant device fails that background connection even after the initial consent succeeds. Exclude that one service-mailbox account from the device-compliance CA policy and it connects. Best, Gabriela

Area Sistemi

Hi Gabriela,

Thank you for the clarification.

That makes sense and is consistent with what we are seeing on our side. I can understand that our corporate Microsoft Entra ID policies are preventing users from granting consent to third-party applications, which would explain the "Admin approval required" message during the mailbox connection process.

I have one additional question:

Is there any support, either current or planned, for app-only authentication when connecting Microsoft 365 Shared Mailboxes to Jira Service Management?

In our environment, an app-only approach would be preferable since it avoids dependency on a specific user account and aligns better with our security and governance requirements.

Thank you in advance for your feedback.

Best regards

Gabriela - LeanZero

It's a genuine Cloud gap and worth putting to support in those terms. Data Center has a client credentials path on the Graph mail channel and Cloud doesn't.

One to plan around regardless: rotating the password on whichever account you connect drops the channel, and someone has to reconnect it by hand.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management