User Profile
Sayali-MSFT
Joined Nov 01, 2021
User Widgets
Recent Discussions
Re: Web Notifications API from Personal Tab app doesn't work
Hello SGymerATComitFS, Microsoft Teams personal tab apps, even when opened in a popped‑out window, still run inside a controlled WebView environment rather than a full browser, which limits support for APIs like the Web Notifications API. As a result, notifications may appear to work (permissions granted, no errors) but never surface as OS‑level desktop alerts. Because of these platform restrictions, real‑time scenarios like WebRTC alerts cannot reliably use browser notifications inside Teams. The recommended approach is to use a hybrid model—keep the app in Teams for UI and entry, but handle notifications and always‑on functionality in an external browser or PWA, or fall back to Teams‑native mechanisms like bot notifications when external options are not feasible.7Views0likes0CommentsRe: Web Notifications API from Personal Tab app doesn't work
Hello SGymerATComitFS, Web Notifications created using the standard browser Notifications API (new Notification(...)) do not reliably surface as native desktop toasts when your web app is running inside a Microsoft Teams personal tab—even if the tab is popped out into a new window and permissions are granted. This is because Teams hosts tab content within its own controlled runtime environment rather than a full standalone browser, and that host does not consistently forward web-based notification requests to the operating system’s notification center. As a result, the API may appear supported and run without errors, but no system-level notifications are displayed. The Notifications API is designed to allow browsers to show system notifications outside the web page viewport, but actual delivery depends on the host environment, and embedded shells like Teams may restrict or ignore them for security or platform consistency reasons. Couple clarification questions: Do you need notifications while the user is not actively focused on Teams, or only while Teams is open? Are you able to support an installed PWA (same URL, installable) as the “always-on + notifications” runtime, with Teams acting as the entry point?19Views0likes0CommentsRe: Get all AA/CQ with Resource Accounts
Hello JFM_12, The supported approach is to query AAs and CQs separately and then join them with resource accounts via application instance associations. At a high level, the process is: Use Get-CsAutoAttendant and Get-CsCallQueue to retrieve all AAs and CQs. Use Get-CsOnlineApplicationInstance to retrieve all resource accounts. For each AA and CQ, check whether a resource account is associated by matching the ConfigurationId using Get-CsOnlineApplicationInstanceAssociation. If no associated resource account is found, treat that entry as missing a resource account. Microsoft documents that each Auto Attendant or Call Queue is expected to have a resource account, but the platform does allow misconfigured or orphaned objects to exist (for example, after deletions or failed provisioning), which is why this audit is useful. As reference: Resource accounts are required and managed separately: https://learn.microsoft.com/en-us/microsoftteams/manage-resource-accounts Associations between resource accounts and AAs/CQs are handled via Online Application Instance associations: https://learn.microsoft.com/en-us/powershell/module/skype/new-csonlineapplicationinstanceassociation If you want to avoid writing custom logic from scratch, community tools such as TeamsAACQTools already implement this correlation logic and can export AA/CQ configurations alongside their resource accounts: https://github.com/ashhw/TeamsAACQTools21Views1like1CommentRe: Get all AA/CQ with Resource Accounts
Hello JFM_12, To identify Auto Attendants (AA) and Call Queues (CQ) that do not have Resource Accounts assigned, you must correlate voice apps, resource accounts, and their associations using Microsoft Teams PowerShell. This involves retrieving all Auto Attendants, Call Queues, and Resource Accounts, mapping them using Get-CsOnlineApplicationInstanceAssociation, and exporting the results to identify any missing assignments. Since neither Microsoft Graph nor the Teams Admin Center currently provides this relationship in bulk, PowerShell remains the only supported method for performing this type of tenant-wide audit. You must use: Get-CsOnlineApplicationInstanceAssociation Reference Document- 1. Manage resource accounts for service numbers - Microsoft Teams | Microsoft Learn 2. PowerShell cmdlet reference for Auto attendants and Call queues - Microsoft Teams | Microsoft Learn 3. Get-CsOnlineApplicationInstanceAssociation (MicrosoftTeams) | Microsoft Learn 4. Get-CsAutoAttendant (MicrosoftTeams) | Microsoft Learn18Views0likes0CommentsRe: When I install my app to a second channel in Teams, the this.onMessage will nto trigger
Hello markofarl, The behavior you’re seeing is expected and results from how Microsoft Teams handles bot installation scopes. Initially, the bot is installed at the team scope, so it is treated as a participant in all team channels. In this mode, the bot receives all channel messages through onMessage, even when users do not mention the bot. When the bot is later installed again at the channel scope in another channel, Teams treats this as a separate installation with different messaging rules. Channel-scoped bots only receive messages when they are explicitly mentioned using @botname. As a result, normal channel messages in that channel are filtered and never delivered to the bot service, which is why onMessage does not fire and no errors or logs appear. Other listeners such as conversation updates, member changes, or installation events continue to work because they are system events, not user message events, and therefore are not restricted by mention requirements. This behavior is not a bug in the Bot Framework SDK or your bot code, but rather a Teams design decision related to installation scope. The recommended solution is to avoid installing the same bot in multiple scopes. For scenarios where the bot should read all channel messages, it should be installed only at the team scope, and the Teams app manifest should restrict the bot to "scopes": ["team"] to prevent channel-level installations. In short, installing the same bot at both team and channel scope changes message delivery rules, and channel-scoped installations require explicit @bot mentions for messages to reach the bot.34Views1like1CommentRe: Issue with Teams 'Add a User to Group Chat' API call?
Hello AutomatonSolutionsRDE, The request fails due to two issues: first, the @odata.type value was misspelled, causing Microsoft Graph to stop processing and return a misleading schema error. Second, an incorrect property was used instead of user@odata.bind. Correcting both issues resolves the problem. The proper request body must include the correct @odata.type, roles array, and the user@odata.bind reference to the target user. { "@odata.type": "#microsoft.graph.aadUserConversationMember", "roles": [], "user@odata.bind": "https://graph.microsoft.com/v1.0/users('USER_ID')" }71Views0likes3CommentsRe: [iOS] Custom App Icon still renders as white square
Hello XianYunTang, We were able to reproduce the issue in the [Mobile (iOS)] Teams version [7.22.77.2025223902/1219]. We have reported this as a bug for further investigation. We will keep you updated as soon as we receive further information. Thank you for bringing this to our attention!69Views1like1CommentRe: Bot configuration config/fetch returns same channel ID when switching channels within same team
Hello rasharab, Thank you for your patience! We were able to reproduce the issue. We have reported this as a bug for further investigation. We will keep you updated as soon as we receive further information. Thank you for bringing this to our attention!47Views0likes1CommentRe: Users on iOS can't write to group chat with a bot
Hello Yannick_Malins , We are pleased to inform you that the bug has been fixed! The fix has been verified in the following versions: Mobile (iOS)Teams Version [7.20.77.2025203102/1113] Please verify on your end and confirm if everything is working as expected. If you encounter any further issues, feel free to reach out. Thank you for your patience!44Views0likes0CommentsRe: Issue with Teams Tab App
Hello achebrol, Intermittent connectivity issues in a Teams tab app—especially when hosted on AKS—typically stem from network routing, DNS delays, or transient connectivity failures rather than actual app downtime. Because retries usually succeed, the app is likely healthy, but some requests fail to reach it. Troubleshooting should start with checking detailed error messages and network traces in Teams to identify whether the failure is due to DNS, TLS, or HTTP routing issues. Common causes include DNS resolution delays, certificate or TLS problems, ingress or load balancer instability, and client-side proxy or network constraints within Teams. To diagnose the issue, review AKS ingress and application logs, test DNS resolution, examine ingress health, verify SSL/TLS configuration, and use network tracing tools. Potential fixes include lowering DNS TTL, adjusting ingress timeouts, ensuring proper health probes, validating Teams manifest domain entries, and using Azure Front Door or Traffic Manager to improve reliability.64Views0likes0CommentsRe: Issue with Teams Tab App
Hello achebrol,Thank you for bringing this issue to our attention. To assist you better, could you please provide the following details? Reproduction Steps: Please share the steps you took to encounter the issue. Documentation Links: Any specific documentation you followed that relates to your problem. Teams Client Version: What version of the Teams client are you using? Code Snippets: Relevant code snippets that illustrate the issue. Manifest Package: If applicable, please share the manifest package for your app. This information will help us better understand the situation and provide a more accurate response.42Views0likes0Comments
Groups
Copilot Studio User Group
A user-led group for Copilot Studio enthusiasts to discuss features, share tips, and participate in virtual topic-based events. This group is run by users and is not an official Microsoft support channel.Latest Activity: Apr 15, 2026Recent Blog Articles
No content to show