Microsoft Teams App Permissions for AI Incident Assistant
AI Incident Assistant, also known as Biggy, integrates with Microsoft Teams using a dedicated app registration in your Azure AD / Entra ID tenant.
To deliver incident management features such as conversation routing, AI-powered incident reports, bridge meetings, and in-chat collaboration, the app uses a defined set of Microsoft Graph application permissions. This page documents each permission, the Graph API endpoints it gates, the specific scenarios where Biggy uses it, and why the permission is required.
All permissions listed here are application-level permissions, which means they run without a signed-in user. Your Azure AD / Entra ID administrator grants them through admin consent, and they apply only to the Biggy app registration.
Biggy also uses Resource-Specific Consent (RSC) permissions, scoped to individual teams and chats.
Application permissions overview
Requirement levels in this document use three categories:
Core required: needed for the bot's baseline operation in its current architecture
Required for specific features: needed for a supported feature area, but not for every deployment
Optional: enhancement-only, or only needed if a customer chooses that feature
The following table summarizes all application permissions Biggy requests and their purposes.
Permission | Requirement Level | Purpose |
|---|---|---|
Core required | List and resolve channel names/descriptions for routing, incident workflows, and destination selection | |
Core required | Read chat metadata (names, type, members) in chats where Biggy is installed. | |
Core required | Read chat messages in chats where Biggy is installed. | |
Core required | Send and update messages in chats where Biggy is installed. | |
Core required | Read tenant organization metadata for installation and onboarding | |
Required for specific features | Download hosted image and file content embedded in Teams messages for incident reports and indexing. | |
Required for specific features | Create incident bridge meetings and channel-linked collaboration meetings. | |
Optional | Retrieve user profile photos for incident report generation. | |
Core required | List teams for destination pickers, routing, incident workflows, and team-based navigation. | |
Core required | Read team membership for onboarding and installation tracking. | |
Core required | Check whether Biggy is installed in a team or chat before offering it as a destination. | |
Required for specific features | Detect personal-scope installation, resolve user DM chat, and proactively install Biggy for users during incident workflows | |
Required for specific features | Install Biggy into meeting chats and grant the required RSC permissions for incident workflows. | |
Core required | Resolve user identity, display names, and email |
Channel.Read.Basic
Microsoft description: Read all channel names and channel descriptions without a signed-in user.
Microsoft documentation:
Graph API endpoints used for Channel.Read.Basic
Method | Endpoint |
|---|---|
|
|
|
|
|
|
How Biggy uses this permission:
Conversation destination picker. When you open the Major Incident Management (MIM) creation dialog or any workflow that targets a Teams channel, Biggy lists all channels for each of your teams in a searchable dropdown. The dropdown lets you select where to post an incident update, summary, or notification. The call is
GET /teams/{teamId}/channelsfor each relevant team, often batched for performance.Incident channel resolution. When an incident is created in a specific channel, Biggy calls
GET /teams/{teamId}/channels/{channelId}to resolve the channel's display name and description. This metadata is used in incident cards, banners, and reports.Installation-time channel sync. When Biggy is added to a team, channel metadata is synchronized so that later features (routing, search, incident creation) can reference accurate channel names without additional API calls.
Requirement level:
Core required. Channel interactions are fundamental to Biggy's primary operating model in Teams. Virtually every operational workflow, such as incident management, MIM, channel summaries, broadcasts, and notification routing, requires the ability to list and resolve team channels.
If this permission is not granted:
Biggy cannot list or resolve any team channels. The conversation destination picker will display teams with no channels to choose from, rendering incident creation, MIM, channel summaries, broadcasts, and any channel-targeting workflow non-functional. Users would be unable to direct the Biggy's output to any team channel.
What this permission does not allow
This permission reads only channel names, descriptions, and basic metadata. It does not grant access to channel messages, files, or member lists.
Why this permission is needed
Biggy's core workflow in Teams is channel-centric: users create incident channels, post summaries to them, route notifications to them, and manage major incidents through them. Channel metadata resolution is a prerequisite for all of these interactions. Without it, the app cannot present valid destinations, and the primary Teams experience breaks entirely.
Installed Chat Permissions (Chat.ReadBasic.WhereInstalled, Chat.Read.WhereInstalled, and Chat.ReadWrite.WhereInstalled)
This group of three permissions controls what Biggy can do in chats where it has been installed. The permissions are scoped to the WhereInstalled variant, meaning the app cannot access arbitrary chats across the tenant.
Permissions:
Chat.ReadBasic.WhereInstalledChat.Read.WhereInstalledChat.ReadWrite.WhereInstalled
Microsoft descriptions:
Chat.ReadBasic.WhereInstalled: Read names and members of one-to-one and group chats where the associated Teams app is installed, without a signed-in user.
Chat.Read.WhereInstalled: Read one-to-one and group chat messages for chats where the associated Teams app is installed, without a signed-in user.
Chat.ReadWrite.WhereInstalled: Read and write one-to-one and group chat messages for chats where the associated Teams app is installed, without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
How Biggy uses these permissions
Resolving your personal DM chat with Biggy. When Biggy needs to send you a proactive message, for example a workflow result or notification, it calls
GET /users/{userId}/chats?$filter=chatType eq 'oneOnOne'to find the 1:1 chat between you and the Biggy bot. This is required because the Bot Framework does not always surface the chat ID.Conversation destination picker (group chats). When you are selecting where to route an incident update or notification, Biggy lists your group chats via
GET /users/{userId}/chats?$filter=chatType eq 'group'. Group chat names and members are resolved so the picker shows recognizable destinations.Reading chat history for incident reports. When you request an incident report from within a chat, Biggy calls
GET /chats/{chatId}/messageswith pagination to read the conversation history for the configured time window. Messages are normalized and fed to the AI to produce a structured incident report. This is the same flow that powers incident reports in channels, adapted for chat-based incidents.Reading chat history for AI context (conversation lookback). During major incident management (MIM), Biggy backfills recent conversation context from a chat. This gives the AI agent awareness of what has already been discussed, preventing redundant questions and enabling more targeted incident triage.
Image and file detection in group chats. When a user shares an image in a group chat, the Bot Framework activity sometimes does not include the attachment metadata for drag-and-dropped files. Biggy calls
GET /chats/{chatId}/messages/{messageId}through the Graph API to check whether the message actually contains image attachments. If it does, Biggy prompts the user to copy-paste instead.Chat member resolution. Biggy calls
GET /chats/{chatId}/members(individually or batched) to resolve the participants of group chats. This is used in the conversation picker to display member names for unnamed group chats, and to enrich incident report participant lists.Chat access validation. Before offering a chat as a routing destination, Biggy uses
POST /$batchwithGET /chats/{chatId}/messages?$top=1to validate that the app has read access to the chat. Chats where access fails are excluded from destination lists.Channel summary and multi-context generation. When generating summaries or multi-context AI outputs that span chat conversations, Biggy reads the full chat message history and normalizes it alongside channel data for unified analysis.
Proactive incident updates in meeting and group chats. When a major incident is declared, and a bridge call is created, Biggy posts a "war room" banner card into the meeting chat with severity, status, and quick-action buttons. As the incident progresses, it updates that same card in place to reflect status changes (e.g., severity escalation, new responders joined, resolution). Workflow results and notifications are also delivered proactively into chats where the user initiated them.
Requirement level:
Chat.ReadBasic.WhereInstalled: Core required. Needed for chat metadata and participant resolution across all installed chat experiences, including DM chat resolution for proactive notifications.
Chat.Read.WhereInstalled: Core required. Needed for reading chat messages to power incident reports, AI-driven triage, conversation lookback, summaries, and image detection.
Chat.ReadWrite.WhereInstalled: Core required. Needed for proactive incident updates, status card updates, and workflow result delivery in installed chats.
If these permissions are not granted:
Without Chat.ReadBasic.WhereInstalled, Biggy cannot reliably identify installed chats, resolve participants, or present recognizable chat destinations. The conversation destination picker will not display group chats.
Without Chat.Read.WhereInstalled, chat-based summaries, incident reports, conversation lookback, and other chat-reading experiences will be unavailable.
Without Chat.ReadWrite.WhereInstalled, Biggy cannot post live incident status updates into meeting chats, update progress cards in place, or deliver workflow results proactively into chats. Users would only see bot responses to direct messages, not proactive updates.
Why all three tiers are needed
Each permission tier unlocks a distinct capability:
Chat.ReadBasic.WhereInstalledenumerates and displays chat metadata (names, type, member count) in destination pickers, and resolves the DM chat ID.Chat.Read.WhereInstalledreads actual message content for incident reports, AI context lookback, channel summaries, and image attachment detection.Chat.ReadWrite.WhereInstalledallows Biggy to proactively send and update messages in chats where it is installed. For example: posting incident status updates, updating progress cards, and delivering workflow results into meeting chats.
Scope limitation
All three permissions are scoped to WhereInstalled. Biggy can only access chats where the Teams app is explicitly installed. It cannot read or write to arbitrary chats across the tenant.
Why these permissions are needed
Biggy's Teams' value depends on conversational awareness. Incident reports, AI-driven triage, channel summaries, and proactive notifications all require reading chat history and metadata from chats where Biggy is actively installed. The WhereInstalled scope ensures this access is limited to only those conversations where your team has chosen to deploy the app.
Organization.Read.All
Microsoft description: Read organization properties, such as an organization's display name, verified domains, and tenant ID, without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
How AI Incident Assistant uses this permission
Tenant onboarding during app installation. When a Teams admin or user installs AI Incident Assistant personally, into a group chat, or into a team; AI Incident Assistant calls
GET /organization/{tenantId}to retrieve the tenant's display name and verified domains. This information is used to associate the installation with the correct Microsoft 365 tenant in the AI Incident Assistant backend, display the tenant name in the onboarding welcome card, and validate tenant identity for multi-tenant deployments.Bot-added-to-team handler. When AI Incident Assistant is added to a team, the same tenant lookup run to ensure the team's tenant is recognized and properly configured.
Requirement level:
Core required. AI Incident Assistant needs tenant identification and tenant scoping as part of its baseline multi-tenant installation and onboarding flow.
If this permission is not granted:
AI Incident Assistant cannot reliably identify the customer tenant during installation and onboarding, which prevents correct tenant association and blocks baseline setup in a multi-tenant environment.
What this permission does not allow
Organization.Read.All is narrowly scoped to the organization object only. It does not grant access to users, groups, directory roles, administrative units, devices, or any other directory objects. This is the least-privileged permission for reading tenant metadata.
Why this permission is needed
AI Incident Assistant must confirm tenant identity at installation to correctly scope all subsequent operations, including data isolation, configuration, and user provisioning. The GET /organization/{tenantId} call is the standard Microsoft-recommended approach for application-context tenant identification. Without this, AI Incident Assistant cannot reliably associate installations with the correct customer Teams tenant.
Files.Read.All
Microsoft description: Read all files in all site collections without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
|
|
|
|
|
|
How AI Incident Assistant uses this permission
Incident report image extraction. When you generate an incident report from a channel or chat, AI Incident Assistant scans the conversation messages for inline images (detected through
<img>tags in message HTML). For each message containing images, AI Incident Assistant calls thehostedContentsendpoint to download the binary image data. These images are base64-encoded and included in the generated incident report PDF or document, preserving visual context like screenshots, diagrams, and monitoring dashboards that participants shared during the incident.Channel indexing and backfill. When AI Incident Assistant indexes historical channel content for search and AI context, hosted content (inline images and files embedded in messages) is retrieved through the same endpoints to build a complete representation of the conversation.
When AI Incident Assistant can and cannot analyze images without this permission
Images AI Incident Assistant can analyze without Files.Read.All: When a user copies and pastes or uploads an image directly in a live conversation with AI Incident Assistant, the image attachment URL is included on the bot framework activity object itself. AI Incident Assistant downloads these images using the bot framework token or via the direct download URL provided by Teams. This covers real-time image analysis in 1:1 chats and group chats; for example, when a user sends an image to AI Incident Assistant and asks a question about it in the moment.
Images AI Incident Assistant cannot analyze without Files.Read.All: When AI Incident Assistant reads historical messages from the Graph API for incident reports, channel summaries, or search indexing, any inline images in those messages are stored by Microsoft as hosted content. These require the Graph API hostedContents endpoint to download, which needs Files.Read.All. Without this permission, incident reports generated from conversation history will be text-only (all screenshots, monitoring dashboards, and diagrams shared during the incident will be missing), and indexed channel content will not include image data.
Requirement level:
Required for specific features. This permission is needed for incident report image extraction and historical content indexing. Features that read conversation history from the Graph API and need to include the images that participants shared.
If this permission is not granted:
Real-time image analysis (for example, when a user pastes an image and asks AI Incident Assistant a question) will continue to work normally. However, incident reports generated from conversation history will not include any inline images. Screenshots of monitoring dashboards, architecture diagrams, or error messages shared during the incident will be omitted.
For example, if a responder pastes a Grafana alert screenshot into the incident channel, that image will appear in the incident report only if this permission is granted. Channel indexing will also be limited to text content only.
What this permission does not allow
While the Files.Read.All permission technically grants access to SharePoint and OneDrive files across the tenant, AI Incident Assistant does not access SharePoint sites, OneDrive folders, or file libraries.
The only file-related Graph endpoints AI Incident Assistant calls are the hostedContents endpoints on chat and channel messages. These retrieve inline content such as images and small files) that users paste or embed directly into Teams messages.
Microsoft requires Files.Read.All as a prerequisite for accessing hosted content on messages in certain scenarios.
Why this permission is needed
Incident reports with visual context (screenshots, graphs, and architecture diagrams) are significantly more useful than text-only reports. The hosted content endpoints allow AI Incident Assistant to include images incident responders shared during the conversation, producing comprehensive reports that capture the full picture of what happened.
AI Incident Assistant does not browse, index, or access any files in SharePoint or OneDrive.
OnlineMeetings.ReadWrite.All
Microsoft description: Read and create online meetings as an application in the organization.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
How Biggy uses this permission
Incident bridge call creation. When you trigger an incident workflow and select Microsoft Teams as the conferencing tool for the bridge call, Biggy calls
POST /users/{systemUserId}/onlineMeetingsto create an online meeting. The meeting is created on behalf of a configured system user (thedefaultUserIdfrom your Teams integration settings). The response includes ajoinWebUrlembedded in the incident banner card, allowing all responders to join the bridge call with a single click. Meeting participants are included in the meeting creation payload when available.Channel-linked collaboration meetings (MIM). During major incident management, the Biggy creates a Teams meeting linked to the incident channel thread via the
chatInfo.threadIdproperty. This associates the meeting with the specific channel conversation, so the meeting chat and channel thread are connected. A transcription bot (Recall) may be added to the meeting to capture a live transcript for later incident analysis.Auto-created incident channel meetings. When an incident channel is provisioned and your organization's configuration includes automatic meeting creation, Biggy creates a channel-linked meeting immediately after channel creation. This ensures a collaboration space is ready before responders even join.
Requirement level:
Required for specific features. This permission is needed for any deployment that uses automated Teams meeting creation as part of incident response, including incident bridge calls, channel-linked meetings, and MIM collaboration meetings. Customers using Zoom or Webex as their conferencing tool instead of Teams are not affected.
If this permission is not granted:
Biggy cannot automatically create Teams bridge calls for incidents. If a user declares a major incident and selects Microsoft Teams as the conferencing tool, the bridge call creation will fail. The incident commander would need to manually create a Teams meeting, copy the join URL, and paste it into the incident channel, adding minutes of manual coordination during a time-critical event. Customers using Zoom or Webex for bridge calls are not affected.
Additional requirement - exchange online application access policy
Creating online meetings in application-only context (no delegated user) requires that your Exchange Online administrator has configured an application access policy that grants the Biggy app permission to create meetings on behalf of the designated system user. This is an Exchange-level policy, separate from the Graph permission itself.
Why this permission is needed
One of Biggy's key incident management capabilities is automating the creation of bridge calls so that responders can immediately collaborate. Without this permission, incident commanders would need to manually create a Teams meeting, copy the join link, and share it, adding critical minutes during an incident. Automated meeting creation reduces mean-time-to-collaborate during incidents.
ProfilePhoto.Read.All
Microsoft description: Read all user and group profile photos without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
How Biggy uses this permission
Incident report participant avatars. When generating an incident report, Biggy resolves each unique message sender from the conversation history. For each human participant, Biggy calls
GET /users/{userId}/photo/$valueto download their profile photo as binary data. The photo is base64-encoded and included in the incident report alongside the participant's name, job title, email, and phone number. This makes incident reports visually rich and allows report readers to quickly identify who said what during the incident.
Requirement level:
Optional. This permission improves report presentation and participant recognition, but it is not required for the bot to function. Incident reports are fully generated with all text content, participant details, and timeline data regardless of this permission.
If this permission is not granted:
Incident reports will render without participant profile photos. All other report content, including messages, timeline, participant names, job titles, emails, and phone numbers, remains fully intact and unaffected.
What this permission does not allow
Biggy only reads profile photos for users who actively participated in a Teams conversation that is the subject of an incident report. It does not bulk-download or cache profile photos for all users in the tenant.
Why this permission is needed
Profile photos make incident reports significantly easier to read and scan. During post-incident review, quickly identifying participants by face accelerates understanding of the incident timeline. This is especially valuable in organizations where team members know each other visually, but not by name.
Team.ReadBasic.All
Microsoft description: Get a list of all teams without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
How AI Incident Assistant uses this permission
Conversation destination picker (teams list). When you open any workflow that targets a Teams channel (incident creation, MIM, broadcast, or channel summary), AI Incident Assistant calls
GET /users/{userId}/joinedTeamsto build the list of teams you belong to. This populates the first level of the destination picker; the user selects a team, then selects a channel within that team. This picker is the entry point for virtually all channel-based workflows.Installation validation for team destinations. After retrieving the list of joined teams, AI Incident Assistant cross-references each team against its installation records using the
TeamsAppInstallationbatch endpoints to determine which teams have AI Incident Assistant installed. Teams without AI Incident Assistant installed are either filtered out or marked as unavailable, preventing you from selecting destinations where the bot cannot operate.Conversation search and caching. AI Incident Assistant caches team lists to reduce repeated Graph API calls. On first load or cache expiration, the joined-teams list is refreshed and then reused until it expires.
Requirement level:
Core required. Team discovery is the foundation of AI Incident Assistant's channel-based workflow model. Every channel-targeting interaction, from incident creation to MIM to summaries, begins by listing the user's teams so they can navigate to the correct channel. Without this, the primary Teams interaction model is not functional.
If this permission is not granted:
Ai Incident Assistant cannot list any teams. The conversation destination picker will be empty at the top level, meaning users cannot select a team or navigate to a channel for any workflow. Incident channel creation, MIM, channel summaries, broadcasts, notification routing, and all other channel-targeting features become completely non-functional.
Why this permission is needed
Every channel-targeting workflow in AI Incident Assistant starts with team discovery. Without knowing which teams you belong to, AI Incident Assistant cannot present valid destinations for incident channels, summaries, broadcasts, or MIM workflows. This permission enables the fundamental navigation experience that connects you to your Teams workspace structure.
TeamMember.Read.All
Microsoft description: Read the members of all teams without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
How Biggy uses this permission
Team onboarding and member tracking. When Biggy is installed into a team, it calls
GET /teams/{teamId}/membersto retrieve the current team roster. This information is used to track which users have access to Biggy in team context, pre-provision user records for team members so that subsequent interactions are seamless, and understand the scope of the installation for analytics and configuration.Installation reconciliation. When team membership changes (members are added or removed), the Biggy conversation install tracker uses member data to keep its internal records in sync with the actual team roster.
Requirement level:
Core required. This permission is needed for accurate team-scoped onboarding, membership-aware setup, and installation tracking.
If this permission is not granted:
Biggy cannot accurately reconcile team membership during onboarding, which limits team-based provisioning, installation tracking, and other membership-aware team experiences. User records for team members will not be pre-provisioned. They will instead be created on demand when each member first interacts with Biggy individually.
Why this permission is needed
Biggy needs team membership data to correctly provision and manage access for team-based experiences. Knowing who is on a team at installation time allows Biggy to set up user records, configure permissions, and ensure that team members have a seamless first interaction with the bot. Without this, user provisioning would be delayed until each team member individually interacts with Biggy.
Teams App Installation Permissions (TeamsAppInstallation.Read.All, TeamsAppInstallation.ReadWriteAndConsentSelfForUser.All, and TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All)
This group of three permissions controls how AI Incident Assistant discovers existing installations, installs itself into meeting chats, and installs itself for individual users.
Permissions:
TeamsAppInstallation.Read.AllTeamsAppInstallation.ReadWriteAndConsentSelfForUser.AllTeamsAppInstallation.ReadWriteAndConsentSelfForChat.All
Microsoft descriptions:
TeamsAppInstallation.Read.All: Read the Teams apps installed in any scope without a signed-in user. Does not allow reading app-specific settings.
TeamsAppInstallation.ReadWriteAndConsentSelfForUser.All: Allow a Teams app to read, install, upgrade, and uninstall itself for any user, without a signed-in user, and manage its permission grants for accessing those specific users' data.
TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All: Allow a Teams app to read, install, upgrade, and uninstall itself for any chat, without a signed-in user, and manage its permission grants for accessing those specific chats' data.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint | Permission |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TeamsAppInstallation.Read.All — team and chat installation validation
Team destination validation. Before presenting a team as a valid destination in the conversation picker, AI Incident Assistant batch-validates that the app is installed in each candidate team. The call
POST /$batch includes GET /teams/{teamId}/installedApps?$filter=teamsAppDefinition/authorization/clientAppId eq '{appId}'for each team. Teams where AI Incident Assistant is not installed are filtered from the destination list, preventing you from selecting teams where the bot cannot operate.Chat installation validation. Similarly, for group chat destinations, AI Incident Assistant batch-validates that the app is installed in each candidate chat through
GET /chats/{chatId}/installedApps?$filter=....This ensures that only accessible chats appear in destination pickers.Group chat discovery with app filter. When building the list of group chats where AI Incident Assistant is installed, AI Incident Assistant first lists your group chats, then batch-checks each chat's installed apps to filter down to only those chats where it is present.
TeamsAppInstallation.ReadWriteAndConsentSelfForUser.All — personal scope detection and installation
Personal app installation check. During onboarding and certain workflow submissions, AI Incident Assistant calls
GET /users/{userId}/teamwork/installedApps?$expand=teamsAppto determine whether you already have AI Incident Assistant installed in personal scope. This prevents duplicate installation attempts and enables features that require personal scope, such as DM-based workflows.Personal app chat resolution. Once a personal installation is confirmed, AI Incident Assistant calls
GET /users/{userId}/teamwork/installedApps/{installationId}/chatto resolve the 1:1 chat ID associated with that installation. This chat ID is needed to deliver proactive messages (notifications and workflow results) to your personal AI Incident Assistant chat.Proactive personal installation for MIM. When you create a major incident through the task module and do not have AI Incident Assistant installed in your personal scope, the MIM submission handler calls
POST /users/{userId}/teamwork/installedAppsto proactively install AI Incident Assistant for you. This is a write operation that requires theReadWriteAndConsentSelftier of this permission. It ensures the user can receive personal notifications and updates related to the incident they just created, without requiring them to manually install the app first.
TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All — meeting chat installation
Incident meeting chat bot installation. When AI Incident Assistant creates an incident bridge meeting, the resulting meeting has an associated meeting chat. AI Incident Assistant installs itself into that meeting chat and requests the chat-scoped permissions it needs in that specific conversation. Incident bridge meetings are created programmatically and immediately. There is no opportunity for an admin or user to manually add AI Incident Assistant to the meeting chat before responders join. Self-installation ensures zero-friction bot presence in meeting chats the moment they are created. This is essential because:
The bot must be in the meeting chat roster to post incident updates and banner messages
RSC permissions are needed for the bot to read meeting chat messages and manage the incident workflow within the meeting context
Without this self-installation, the meeting chat would be inaccessible to AI Incident Assistant
Meeting summary chat bot installation. When AI Incident Assistant needs to deliver a meeting summary to a meeting-linked chat, it first ensures it is present in the chat before attempting to post. If the app is already installed, that condition is handled gracefully.
Error handling
If chat self-installation fails because the required permission has not been granted, AI Incident Assistant surfaces a user-facing error message directing the admin to grant TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All in the Azure Portal. This is the only permission whose name is explicitly surfaced to end users in error messages.
Requirement level:
TeamsAppInstallation.Read.All: Core required. Installation validation is used by the conversation destination picker to ensure users can only select teams and chats where AI Incident Assistant is installed. Without this, every destination selection becomes a gamble. Users may select a team or chat where the bot cannot operate, resulting in failed workflows and confusing errors.
TeamsAppInstallation.ReadWriteAndConsentSelfForUser.All: Required for specific features. Needed for personal-scope installation checks, personal-chat resolution, and proactive user-scope installation during major incident workflows. The write and consent tier is required because AI Incident Assistant proactively installs itself for users who create major incidents, ensuring they can receive personal notifications without manual setup.
TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All: Required for specific features. Needed for self-installation into meeting chats during incident bridge workflows. Without this, the bot cannot join meeting chats programmatically, and the incident bridge meeting feature will not function correctly.
If these permissions are not granted:
Without TeamsAppInstallation.Read.All, AI Incident Assistant cannot verify whether it is installed in candidate teams and chats. The destination picker will either show all teams/chats (including ones where workflows will fail) or show none. Users will encounter broken workflows when they select a destination where AI Incident Assistant is not actually installed.
Without TeamsAppInstallation.ReadWriteAndConsentSelfForUser.All, AI Incident Assistant cannot verify personal installation state, resolve the user's personal AI Incident Assistant chat, or proactively install itself for users during major incident creation. Personal-scope and direct-message workflows will be unavailable.
Without TeamsAppInstallation.ReadWriteAndConsentSelfForChat.All, AI Incident Assistant cannot join meeting chats created during incident bridge call workflows. The incident meeting will be created, but AI Incident Assistant will not be able to post status updates, banner cards, or manage the incident workflow within the meeting chat.
Why this permission is needed
The read permissions ensure that AI Incident Assistant only offers destination teams and chats where it is actually installed and authorized to operate. This prevents broken workflows, failed message deliveries, and confusing user experiences.
ReadWriteAndConsentSelfForUser is required so that AI Incident Assistant can proactively install itself for users who create major incidents, ensuring they receive immediate personal notifications and updates. Without this, users would need to manually install Biggy before they could receive DM-based incident updates.
ReadWriteAndConsentSelfForChat.All is required for the incident meeting workflow. When an incident bridge is created, the bot must join the meeting chat to post status updates, track the conversation, and manage the incident lifecycle. Without self-installation capability, a human would need to manually add AI Incident Assistant to every meeting chat; an unreasonable friction during time-critical incident response.
User.Read.All
Microsoft description: Read the full set of profile properties, reports, and managers of other users in the organization without a signed-in user.
Microsoft documentation:
Graph API endpoints used
Method | Endpoint |
|---|---|
|
|
|
|
How Biggy uses this permission
User provisioning on first interaction. When you install Biggy yourself or first interact with it, Biggy retrieves your
displayName,mail,givenName,jobTitle, and other profile properties. This data is used to create your record in the Biggy backend, linking your Azure AD identity to your account. If a user with the same email already exists (for example, created through another channel), the accounts are merged rather than duplicated.RBAC and ability resolution. Biggy resolves the Azure AD identity of the current user to determine their permissions and role-based access controls.
Incident report user enrichment. During incident report generation, Biggy resolves every unique message sender from the conversation. For each human participant,
GET /users/{userId}retrieves their display name, job title, email, and mobile phone. This data populates the participants section of the incident report.Meeting participant resolution. When creating an incident bridge meeting, Biggy batch-resolves participant identities (ID, UPN, and display name) for inclusion in the meeting creation payload. This ensures that meeting invitations include proper attendee information.
Forwarded message sender enrichment. When Teams messages contain forwarded content, the original sender's display name is sometimes missing from the forwarded message metadata. Biggy uses directory lookups as a fallback to resolve missing sender display names, ensuring channel summaries and reports correctly attribute forwarded messages.
Conversation picker — unnamed group chat display names. Group chats without a custom name are displayed as a comma-separated list of member names. Biggy batch-resolves the display names of chat members for these unnamed chats.
User resolution for interactive workflows. Various interactive form and dialog flows resolve the identity of the submitting user for attribution and permission checks.
Requirement level:
Core required. User identity resolution is foundational to Biggy's baseline operation, including provisioning, authorization, attribution, and user-aware responses.
If this permission is not granted:
Biggy cannot provision user accounts on first interaction (the onboarding flow fails), cannot resolve user identity for role-based access control (authorization breaks), cannot populate participant details in incident reports, and cannot display user names in unnamed group chats. Effectively, this prevents the bot from functioning because every user interaction requires identity resolution.
What Biggy reads from user profiles
Biggy reads the following properties: id, userPrincipalName, displayName, mail, givenName, jobTitle, and mobilePhone. It does not read sensitive properties like authentication methods, license details, or sign-in activity.
Why this permission is needed
User identity resolution is foundational to Biggy's operation. Every interaction, from the initial installation through incident management, requires knowing who the user is, what their name and email are, and sometimes their role. Query shaping is used where possible to limit the data retrieved to only what is needed.
Resource-Specific Consent (RSC) Permissions
In addition to the tenant-wide application permissions described above, AI Incident Assistant declares a set of Resource-Specific Consent (RSC) permissions. RSC permissions are scoped to individual teams and chats. They only grant access within the specific team or chat where the app is installed, not tenant-wide.
RSC permissions are automatically granted when AI Incident Assistant is installed into a team or chat by a team owner or admin. They do not require separate admin consent in the Azure portal. They are declared in the app manifest and take effect at installation time for that specific resource.
RSC permission | Type | Scope | Requirement Level | What it enables | If not enabled |
|---|---|---|---|---|---|
| Application | Team | Required for specific features | Read messages in team channels where AI Incident Assistant is installed. | Channel-based reading experiences such as channel summaries, reports, and conversation analysis will be unavailable. |
| Application | Team | Required for specific features | Read channel settings (name, description, moderation) in teams where AI Incident Assistant is installed. | Team-channel destination discovery and channel-aware workflows will be unavailable. |
| Application | Chat | Required for specific features | Read messages in chats where AI Incident Assistant is installed. | Chat-based reading experiences such as summaries, reports, and conversation analysis will be unavailable. |
| Application | Team | Required for specific features | Create new channels in teams where AI Incident Assistant is installed, for incident channel provisioning. | AI Incident Assistant will not be able to create dedicated incident channels in teams. |
| Application | Team | Required for specific features | Send messages to team channels where AI Incident Assistant is installed. | AI Incident Assistant will not be able to post proactive messages, incident banners, or notifications to channels. |
| Application | Chat | Required for specific features | Send messages in chats where AI Incident Assistant is installed. | AI Incident Assistant will not be able to post proactive messages or notifications in chats. |
| Application | Chat | Required for specific features | Read chat settings (name, members, type) in chats where AI Incident Assistant is installed. | Chat destination labeling, participant-aware chat experiences, and chat metadata lookups will be unavailable. |
| Application | Team | Required for specific features | Read team settings in teams where AI Incident Assistant is installed. | Team-aware workflows may lose access to team-level configuration metadata. |
| Application | Chat | Required for specific features | Read basic online meeting information in chats where AI Incident Assistant is installed. | Meeting-linked chat workflows may lose access to meeting metadata. |
How RSC complements tenant-wide permissions
RSC permissions provide a defense-in-depth approach. Even though tenant-wide application permissions may cover the same operations (for example, Chat.Read.WhereInstalled), RSC permissions add a per-resource consent layer that is explicitly granted at install time. This gives administrators visibility into exactly what the app can do in each specific team or chat.
Data Handling and Privacy Commitments
AI Incident Assistant applies the following commitments to every Graph API interaction:
No bulk data collection. AI Incident Assistant does not crawl, index, or store tenant-wide data. All Graph API calls are triggered by installation lifecycle events or specific user actions (for example, creating incidents, generating reports, or selecting destinations).
Minimal data retention. User identity data, chat messages, and meeting information retrieved from Graph are used transiently for the specific operation and are not stored long-term, unless they are part of a user-generated artifact such as an incident report that you explicitly requested.
Scoped access patterns. Where possible, AI Incident Assistant uses
WhereInstalledpermission variants and RSC to limit access to only the conversations where the app is deployed. Tenant-wide permissions are used only when the Microsoft Graph API requires them for the specific endpoint.No administrative actions. AI Incident Assistant does not modify directory objects, manage users, change group settings, assign licenses, or perform any administrative operations. All permissions are read-only or scoped to the app's own installation and meeting creation.
Graph API Endpoints by Permission
For quick reference, the following table maps every Graph API endpoint Biggy calls to its required permission.
Permission | Requirement Level | Graph API endpoints |
|---|---|---|
| Core required |
|
| Core required |
|
| Core required |
|
| Core required | Send and update messages in installed chats (through Bot Framework and Graph). |
| Core required |
|
| Required for specific features |
|
| Required for specific features |
|
| Optional |
|
| Core required |
|
| Core required |
|
| Core required |
|
| Required for specific features |
|
| Required for specific features |
|
| Core required |
|