Teams calls reporting as potentially scams incorrectly
Hey Teams Community, In the past 5 days I am seeing callers from external tenants that are trusted and in mto showing as suspected scam callers when they call me. They see.me as a suspected scam also when I call. These tenants are all trusted and most of them are.members of the same MTO. This only started happening in the last 7 days. What is causing this? Does anybody else see this happening recently with a similar setup?
Feature request: Historical Agent Activity Timeline for Microsoft Teams Queues
Hi everyone, We're currently using the new Microsoft Teams Queues app for our IT Service Desk and are very pleased with the improvements Microsoft has introduced. One capability we feel is still missing is a historical Agent Activity Timeline. Today supervisors can only see an agent's current Opt-in/Opt-out status. There is no historical overview showing: When an agent opted in When an agent opted out Which agents were opted in at a specific moment Whether the change was made by the agent, a supervisor or automatically This makes it difficult to investigate: Missed calls Queue performance SLA deviations Staffing questions Incident investigations A simple historical timeline containing the timestamp, queue, agent and source of the status change would already provide tremendous value for supervisors and service desk managers. We've submitted this as a feature request through the Microsoft Feedback Portal: https://feedbackportal.microsoft.com/feedback/idea/2df346ee-bc89-f111-9b47-7c1e52444ef6 If you experience the same limitation, we'd really appreciate your vote. I'm also interested in hearing how other organisations deal with this today. Are you using manual checks, screenshots or another workaround? Thank you! Romain Weimer Head of ICT Operations and Support Witteveen+BosTeams Freezes ~90 seconds into a 1:1 Mac OSX
Teams video and audio starts freezing 90 seconds into a 1:1 call, and then it comes back to normal and wont happen again. This started about 3 weeks ago and it happens only during 1:1 calls wont happen when there are more then 2 people in a call. Mac OSX 26.5.1 (25F80) Teams Version 26149.1804.4788.5681
How can I report an error in MS Teams documentation?
Hey all, how can I report an error that I noticed in MS teams documentation? On this site: https://learn.microsoft.com/en-us/microsoftteams/phone-reference/manage-numbers/phone-number-management-for-slovenia There is a LOA request that is named: "Letter of Authorization (LOA) for Slovania (all numbers) (v.1.0)". This is of course an error - it should say Slovenia, not Slovania. How do I report this to MSFT for checking and fixing the Learn docs? I cannot seem to edit or submit a PR for MS teams. Thanks! BR TimUsing the Small Window for Incoming Teams Calls
A recent improvement is the introduction of a small window for incoming Teams calls. It doesn’t sound like a great step forward, but switching to the small window is a surprisingly useful step. The sad thing is that many users won’t know that the option to switch exists because it’s buried in Teams settings. If you’re a busy person who takes lots of Teams calls, switching is definitely recommended. https://office365itpros.com/2026/06/30/incoming-teams-call-window/How much should Teams presence influence call routing
One thing I've noticed recently is that many Teams Phone environments still treat presence as a destination state rather than a routing input. A typical flow might look like: Caller selects an option Call is transferred User is unavailable Caller ends up in voicemail or another queue Technically the routing worked. From the caller's perspective, it often didn't. I'm curious how others are approaching this. Are you using Teams presence as part of your call-routing logic? For example: Available → transfer immediately Busy → offer an alternative path In a meeting → capture context Offline → route elsewhere Or are traditional queues and escalation paths still sufficient for most scenarios? Interested to hear what people are doing in real deployments.
Stop Automatic Calling when Screensharing
I screenshare a lot in my position; I call the coworker (Phone/Headset) and train them on what I need them to look at. I am in a large office building, and the automatic calling of the receivers' PC is disruptive, as I do not was the whole office to hear my conversation or have people hear my trainee. I see no way to disable the team auto-call once I start to screen share or in the Options. All my coworkers feel this frustration as well. I do use the computer microphone/speaks aspect when working from home, but would disable it totally, if it would stop the auto-call. I do not want it to affect meeting invites to others, as others around the country can use their PC speak/microphone, if they want. Please advise.
Direct Routing PSTN calls to Teams Auto Attendant does not forward to Shared Voicemail
Hi all, I’m running into a strange issue with a Teams Auto Attendant and I’m hoping someone here has seen it before. We have a Direct Routing number where business hours calls go to a Call Queue, which works, and after hours calls should go to Shared Voicemail for a Microsoft 365 Group. If I call the Auto Attendant from inside our Teams tenant, the after-hours Shared Voicemail works correctly. I can leave a message and the voicemail is delivered to the group inbox as expected. If I call the same number from the PSTN over Direct Routing, I hear the after-hours greeting, so the schedule and call flow are clearly being hit, but once the greeting finishes I get: “Sorry, we cannot connect your call at the moment, please try again later.” I have already verified that the resource account has the correct Teams Phone Resource Account license, Enterprise Voice is enabled, the LineURI is assigned, the Online Voice Routing Policy is assigned, the Direct Routing route and SBC look healthy, the Auto Attendant is associated with the correct resource account, the after-hours call flow points to the correct Microsoft 365 Group, and the group mailbox exists and is healthy. What makes this more confusing is that redirects to internal or tenant-side destinations work, but redirect to Shared Voicemail from a PSTN-originated call does not work. I also tested redirect to an external PSTN number, and that fails with the same error as well. Because the after-hours greeting plays correctly, and because internal Teams calls can successfully leave voicemail in the shared mailbox, I do not think the issue is with the Auto Attendant configuration itself or with the Microsoft 365 Group mailbox. At this point it looks more like the handoff or redirect path for PSTN-originated calls over Direct Routing is where things break. Has anyone run into this with a Teams Auto Attendant, Shared Voicemail, and inbound PSTN over Direct Routing? I’m trying to figure out whether this is a known limitation, a bug, or if there is some specific setting related to PSTN-originated redirects that I am missing. Thanks!
