Automatic initials are taking my business
Hello everyone, I'm a software developer, mostly based in Germany. I have a M365 Business Account and am using Teams as part of it. Since automatic initials, instead of generic profile pictures, became a thing, I'm constantly in a hurry to change my profile picture as soon as possible. This is because my initials are SS, which in the German culture is the abbreviation of the company responsible for the death camps during Nazi Germany. People are so upset about it that I even had customers not do business with me. They saw the SS initials in calls and thought I was using this on purpose to make a political stand, i.e. being in favour of the industrial scale mass murder of several million people. I'm not. So here is where my frustration is with Teams, which I'm paying for, and which is taking my business away with its stupid initials: I cant change the initials without changing my name I cant populate my picture to outside orgs preventing the initials from being shown This leads me to the incredibly uncomfortable situation that every time I connect to a new client, I need to discuss my distancing of the genocide 80 years ago before actually being able to commence a meeting. Not a very happy topic and as mentioned before I have lost business because of it. Is there please, any solution to this, that doesn't involve having to change my name? Kind Regards SebastianThe Misleading Teams Remove External Chat from User View API
The Graph removeAllAccessForUser API is supposed to remove external chat messages from the view of a tenant user when the chat contains some objectionable material. Unless the documentation is erroneous, the API doesn’t work as advertised and the results are disappointing. All of which means that blocking content for external chats isn’t really possible. If someone gets to start an external chat, they can pump some horrible stuff into your tenant. https://office365itpros.com/2026/07/02/external-chat-api/
Don't expire attached chat files | Show a warning.
Teams allows users to upload files to share with others in a chat. These files inherit the organization's sharing policy. So whether you use Share or Copy Link in SharePoint or OneDrive or you use Attach File in Teams, the same default policy is applied. The issue, what makes the Teams experience different from SharePoint / OneDrive, is that the message with the attached file persists in the chat. A file that was attached to a conversation two months ago appears to still be in the chat. However, the default policy blocks access to the file that appears present. Moreover, there is no method for the sender to alter the sharing policy using the Attach function. When this an issue, this is a HUGE issue. Suggestions: Actually attach the attached file and store in the recipient's Attachments folder. Don't use a paperclip icon that says "Attach file" for files that aren't actually attachments. Warn the sender that the attached file inherits the organization's 'Share with anyone' policy and may expire. Prompt the sender to alter the sharing link before sending. Put a timer on the attachment showing the countdown to expiration. After the expiration date, the file should be labeled "Your organization's sharing policy has expired access to this file". Add a button for the recipient to request access to the file again.
Anyone Else Having Issues?
Hello! My company uses Teams as our main communication channel. For the past two or three weeks we have had significantly more issues than usual with Teams. Messages will sit and not send for sometimes over an hour. We have tried the standard troubleshooting methods and are still facing this problem. Is it just us or is this a bug? If so, is Microsoft working on a solution? Thank you!How to Remove Teams Chat Threads with PowerShell
Sometimes, Microsoft 365 tenants need to remove problematic Teams chat threads from user view. The usual reason is because someone posted some bad or objectionable content to Teams. This article covers how to use Microsoft Graph PowerShell SDK cmdlets to find chat threads, to check thread messages for targeted content, and to remove matching chat threads. The code can be run interactively by an administrator to clean up Teams. https://office365itpros.com/2026/06/15/delete-teams-chat-threads/
Introducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 here
Planner task comments no longer send email notifications – critical regression
This change removed a previously existing core functionality without providing an adequate replacement. With the new Planner experience, task comments no longer trigger automatic email notifications to assigned users. This breaks a critical communication mechanism that many teams relied on for reliable task coordination. As a result, assigned users are no longer consistently informed about updates, introducing a high risk of missed information and operational issues in day-to-day work. There is currently no supported or enforceable alternative to ensure users are notified. Previous behavior: Task comments triggered automatic email notifications Assigned users were reliably informed Communication was traceable and consistent Current behavior: No automatic email notifications No configuration to restore this @mentions required (manual, error-prone, not enforceable) Microsoft Support has confirmed that this is by design and cannot be reverted. From an enterprise perspective, this is not just a design change, but a regression of critical functionality without an equivalent replacement. Request: Please restore automatic email notifications for task discussions or provide a reliable, enforceable alternative for notifying assigned users. Question to the community: How are you handling this change in real-world scenarios? Switching tools? Enforcing @mentions? Moving communication out of Planner? Would appreciate hearing how others are dealing with this.How to find pictures/screenshots in a chat
HI All We use teams chat to share screenshots all the time, but it seems these shared screenshots are not saved in the file tab. It is very difficult to browse through the complete chat history to find them because I cant find a way to filter all the pictures, etc. Does anyone know the trick? Thanks
