This guide is for Jira administrators who need to configure Microsoft 365 for Jira and want to understand the basics of the Microsoft ecosystem and what they need from their Microsoft 365 / Azure AD administrators. If you walk through this page, you should be "covered" for a standard rollout.

Before you start, it helps to map familiar Atlassian concepts to the Microsoft world:

• Atlassian OAuth 2.0 app → Microsoft Enterprise Application

  You know this as: creating an OAuth 2.0 integration where you define who can log in and which scopes are granted.

  Microsoft equivalent: an Enterprise application in Azure Active Directory (Entra ID).
  
  

• Scopes / Permissions

  Atlassian OAuth 2 scopes define what the app can do on behalf of a user.

  Microsoft equivalent: API permissions (scopes) on the Enterprise app.
  
  

• User‑based vs. App‑based permissions

  Atlassian OAuth 2 scopes are always evaluated in the context of the logged‑in user. App permissions that have access to all resources are only available for Forge/Connect apps.
  
  

  In Microsoft you have:

  • delegated (user‑based) permissions, the get a permission to act on behalf of the user. The app can do everything the user can for that specific permission. E.g. permission Mail.Read means, the app can read all mails of the user. These are the permissions our app uses the most, as it ensures the Microsoft permission model is in place.

  • application permissions, the app get permissions to do something tenant-wide. E.g. Mail.Read as application permissions would mean, that the app can read all mails of all users. By default we do not use these permissions, because the app is responsible for managing the permissions.

  • RSC (resource‑specific consent) which allow the app itself to act on a resource like a Teams chat or channel. The permissions is, as the name suggest, not tied to a user, but on a specific resource, like a specific Chat. The app then has full access to that chat independent of the users but not other chats in the tenant.

Now you know the basics, we can start:

Open

This is the first and most important step. Without this, users cannot sign in with their Microsoft work accounts.

In Microsoft Entra ID (formerly Azure AD), an Enterprise application is the tenant-specific instance of our app which controls who can sign in and which permissions/scopes are granted.

For your purposes as Jira admin, it helps to think of the Enterprise application as:

"The Microsoft OAuth2 app configuration for Microsoft 365 for Jira – who can log in and what the app can do."

You usually cannot create or fully configure the Enterprise app yourself unless you also have Entra ID admin rights. From the Microsoft 365 administrator you need the following:

1. Create or locate the Enterprise application used by Microsoft 365 for Jira (based on our app registration or marketplace app instructions).

2. Configure who can sign in:

   • Option A: allow sign‑in for all users in the tenant.

   • Option B: limit to specific users/groups (for pilot phases or controlled rollouts).

3. Admin‑consent the scopes so users are not prompted individually (recommended).

It is strongly recommended that the Microsoft admin grants consent for all required scopes centrally:

• Users get a seamless SSO experience without unexpected consent prompts.

• You avoid support tickets from users who see confusing permission dialogs.

• It gives you and security a clear, auditable overview of what the app can do.

Admin consent here is comparable to an Atlassian site admin approving scopes for an OAuth app globally.

Once the Enterprise app is configured and the required delegated scopes are consented:

• Users can log in to Microsoft 365 for Jira using their Microsoft work accounts.

• Mail, calendar, and most Microsoft 365 features integrated into Jira will work.

• Exception: Teams channel conversations will not work yet – these require RSC (resource‑specific consent) via the Teams app, which is covered in section 4.

Microsoft uses different kinds of scopes/permissions. For Microsoft 365 for Jira you will encounter primarily:

• Delegated scopes

• RSC (resource-specific consent) scopes

Delegated scopes are closest to what you know from Atlassian OAuth2:

• They allow the app to act on behalf of the signed‑in user.

• Every action is limited by the user's own permissions in Microsoft 365.

• These are considered lower risk because the app cannot exceed user permissions.

Examples (exact scopes depend on the Microsoft 365 for Jira version and documentation):

• Read user profile information.

• Access the user's calendar and mail.

• Read Teams messages where the user is a member (if configured).

From a Jira admin perspective this means:

• If a user cannot do something in Microsoft 365 directly, the integration also cannot do it for them.

• You usually only need the Microsoft admin once to configure and consent these scopes globally.

RSC (resource-specific consent) scopes are different:

• They are app-based, not tied to a specific user.

• They are granted per resource – in this case, a Teams chat or Teams channel.

• They allow the app to manage that specific resource (such as read or write messages) even when a particular user is not online.

For Microsoft 365 for Jira, RSC scopes are required for:

• Teams chat integration – managing a chat.

• Teams channel integration – managing a channel and its conversations.

You can think of RSC scopes as:

"Give this app special permissions to this specific Teams chat or channel so it can manage conversations there."

RSC scopes are not configured centrally in the Enterprise application UI alone. They are granted by installing the Teams app into the target chat or channel.

When the Microsoft 365 for Jira Teams app is installed into a chat or channel, Microsoft:

• Associates the app with that specific chat or channel (the resource).

• Grants the app the RSC permissions it requested for that resource.

Result:

• The app can now manage that chat or channel as allowed by the granted scopes.

• Jira can display and synchronize Teams conversations and perform actions such as posting messages in that chat or channel.

Depending on your organization’s policies, installing apps into Teams channels or chats might be restricted. If you as Jira admin cannot do this yourself, you need a Teams or Microsoft 365 admin to:

1. Enable the Microsoft 365 for Jira Teams app in the tenant (if necessary).

2. Install the app into the desired Teams channels and chats.

3. Confirm that the app has the required RSC permissions for those resources.

Important: installing the app into the channel is what makes Teams channels and their conversations work with Jira. Without this, Jira can still work with Microsoft 365 in general, but Teams channel conversations will not be available.

To be fully covered when configuring Microsoft 365 for Jira, ensure the following are in place:

1. Enterprise application for Microsoft 365 for Jira

   • Created in Entra ID or Azure AD.

   • Correct redirect URLs for your Jira instance.

   • Access allowed for all intended users or groups.

2. Delegated scopes configured and consented

   • Required Microsoft Graph and related delegated permissions are added.

   • A Microsoft admin has granted admin consent for these scopes.

3. Teams and RSC setup for conversations (if you use Teams)

   • Microsoft 365 for Jira Teams app is allowed in the tenant.

   • The app is installed into each Teams channel or chat where you want Jira integration.

   • This installation grants the necessary RSC scopes so Jira can manage those chats and channels.

Once these three building blocks are in place, your Microsoft 365 for Jira integration should be fully functional from a Jira administrator's point of view, and you will know exactly where you need help from your Microsoft counterparts.