Loading
PLATFORM
CAPABILITIES
ASANA AI
PLANS
Company Type
Teams
Industries
Use Cases
LEARN
SUPPORT
SERVICES
Help Center
search-icon

Topics

Microsoft Teams for Asana Gov

In This Article

Available to eligible Asana Gov organizations using supported Microsoft Teams paid plans. 

Asana Gov customers can connect Asana to Microsoft Teams. This version focuses on secure communication inside government cloud environments.

Related articles

Requirements

You need an active Asana account in an Asana Gov organization and access to Microsoft Teams with permission to add apps. Your organization may require admin approval before you can install the app. If the installation fails, contact your Microsoft 365 or Asana admin to review app permissions and tenant allowlists.

Asana Gov customers should ensure that users sign in with their Gov organization to keep data routing within supported regions and services.

Install the Asana Gov app in Teams

  1. Open Microsoft Teams and click Apps. 
  2. Search for Asana and select the Asana Gov app. 
  3. Click Add to install it to your Teams client. 

After installation, open the Asana bot in your chats and click Sign in to connect your Asana account. If prompted, select your Asana domain and complete authentication.

Set up personal notifications

Personal notifications let you receive Asana updates in a one-to-one chat with the Asana bot in Teams. 

Open the Asana bot chat and click Link project or type “link project” to choose the Asana work you want to follow, such as My tasks or a specific project. You can update your preferences at any time by opening the Asana bot chat and clicking Settings.

Security and data handling

The Asana Gov app is designed for government cloud requirements and limits functionality to features that meet those standards. Links and notifications honor Asana permissions. Users only see information they can access in Asana.

This integration has undergone functional testing within an Asana Gov instance to ensure all functionality is working as intended. The integration hasn't yet been evaluated and assessed in accordance with FedRAMP security and authorization boundary requirements, but customers can make a risk-based decision and take on any risk due to the integration not being FedRAMP authorized.

OAuth scope explanations

When someone connects their Microsoft account to Asana, Microsoft shows a permissions screen listing what Asana is asking to access.

Each item on that screen is called a scope. These are limited, purpose-specific permissions. They are not broad admin permissions, and they do not give Asana access to unrelated Microsoft data like email, calendars, files, or historical Teams messages.

Active scopes Asana currently requests

Scope

Simple explanation

Why it’s needed

Justification for use

What it does not mean

Screenshot of where this is used

openid

Lets Asana confirm that the person signing in with Microsoft is really the correct user.

This is a standard part of Microsoft sign-in. It gives Asana a secure identity token, allowing Asana to verify the user’s identity after login.

Without this, Asana would not be able to safely trust the Microsoft login.

This scope is about secure sign-in, not about reading Teams content.

profile

Provides Asana with a stable Microsoft account identifier so it can match the Microsoft account to the correct Asana user.

Microsoft accounts can change display names or email addresses over time. Asana needs a permanent, unique ID so the connection continues to point to the right person.

This helps keep the integration reliable and prevents account mismatches.

This is not broad profile scraping. The important part here is the unique account ID.

offline_access

Allows Asana to maintain the connection in the background, so users don't need to sign in again every hour.

Microsoft access tokens expire quickly. This permission allows Microsoft to grant Asana a refresh token, enabling Asana to renew the connection automatically.

Without it, connected features would break frequently, and users would have to reconnect their Microsoft account over and over. This is especially important for Rules that automatically send Teams messages.

It does not give Asana unlimited access to unrelated Microsoft data. It simply keeps the connection active without repeated manual sign-ins.

General entire integration

user.read

Allows Asana to read basic information about the signed-in Microsoft user.

Asana uses this to correctly identify the current user when showing direct-message chat options during Rule setup.


It also uses it to default-assign tasks to the currently signed-in user.


For example, if a user is choosing a 1:1 chat, Asana needs to know which participant is “you” so it can label the chat clearly as the other person rather than showing an ambiguous name.

This supports a clean and understandable setup experience for direct-message automations.

This is basic profile access, not access to email, files, or message history.

team.readbasic.all

Allows Asana to see the names and basic details of the Teams workspaces the user belongs to.

When someone sets up a Rule to send a message to a Teams channel, Asana needs to show them a searchable list of Teams workspaces to choose from.

Without it, the user would be unable to select the correct Team during setup.

This does not give Asana access to messages, files, or full membership details for those Teams workspaces.

channel.readbasic.all

Allows Asana to see the names and basic details of channels inside a Microsoft Team.

After a user selects a Team, Asana needs to display the available channels in that Team so the user can select the appropriate destination for a Rule.

This is necessary to make channel selection usable and accurate.

It does not give Asana access to channel message history or files. It is limited to basic channel information needed for selection.

 

Chat.ReadWrite

Allows Asana to work with the user’s Teams chats for direct-message workflows.

This scope supports two parts of the direct-message Rule experience:


  • Read access: Asana can show the user a list of their recent chats, allowing them to select the correct conversation during setup.

  • Write access: The permission level also supports sending messages into chats for the direct-message automation experience.


Important implementation note for internal use

Today, the actual delivery of Rule-triggered messages is handled through the Asana bot service, not by posting as the user through the user’s Microsoft token. Even so, this scope is still used for the setup and configuration experience around chat selection.

If users want Asana Rules to send messages into Teams chats, Asana needs enough access to identify those chats and support that workflow.

This should not be described as broad access to the entire chat history for general reading. The use case is specifically tied to chat selection and direct-message automation workflows.

What Asana is not requesting

Asana is not requesting:

  • access to past Teams message history
  • access to files or SharePoint content
  • access to email
  • access to calendars
  • admin-level tenant permissions
  • broad organization-wide control over Microsoft Teams

These are user-delegated permissions tied to the specific integration experience, not sweeping admin permissions.

Related articles

Loading
Asana Gov app for Microsoft Teams setup and security | Asana Help Center