Two different Delete-Only Retention Policies for Microsoft Teams chat
I have created two different delete-only retention policies for Microsoft Teams chat. Four of us use a 90-day deletion policy and the rest of our staff use a 30-day deletion policy. My question is: If I am using the 90-day policy and I chat with someone who uses the 30-day policy, will my chats remain visible for 90 days and theirs for 30? Or will the most restrictive policy take over and delete the chats from both sides after 30 days?
Please tell me how to disable the Pin Copilot message
Morning! I wrote a message yesterday but nobody replied, so here's another one so it doesn't get lost Can somebody tell me how to disable the annoying "Pin Copilot Chat" popup? every morning I have to say "Maybe Later" when I really mean to say NEVER IN A THOUSAND YEARS
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 👉 hereIntroducing the RabbitMQ Connector (Public Preview)
We are pleased to announce the introduction of the RabbitMQ Connector in Logic Apps (Standard) which allows you to both send and receive messages between Logic Apps and RabbitMQ. RabbitMQ is a robust, open-source message broker widely used for building reliable, scalable, and flexible messaging solutions. It is trusted across industries such as financial services, e-commerce, IoT, telecommunications, and cloud-native microservices. Our RabbitMQ connector allows messaging scenarios on-premises using Logic Apps hybrid. Benefits of Using RabbitMQ Reliability: RabbitMQ ensures message delivery with strong durability and acknowledgment mechanisms. Flexible Routing: Supports complex routing logic via exchanges (direct, topic, fanout, headers). Clustering & High Availability: Offers clustering and mirrored queues for fault tolerance. Management & Monitoring: Provides a user-friendly management UI and extensive monitoring capabilities. Extensibility: Supports plugins for authentication, federation, and more. Our current connector offering supports both triggers (receive) and sending (publish) within Logic Apps. Receiving Messages To enable a trigger, we need to search for the RabbitMQ connector within our designer. We will discover an operation called When the queue has messages from RabbitMQ show up as a built-in connector. We also have a peek lock operation for non-destructive reads. Search for Trigger and click on this operation to add the trigger to your design surface. Configure the trigger by providing the Queue Name. You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. Publishing Messages To send a message, search for the RabbitMQ connector in your design experience. You’ll find an operation called Send a message. Add this operation to your design surface and Provide the following: Queue Name Message Body Exchange Name (if routing is required) Routing Key Once configured, you can run messages through your solution. To see this in action, refer to the demonstration video (No link found). Completing Messages To Complete messages, in scenarios using peek-lock, search for the RabbitMQ connector within the Logic Apps designer. You’ll find an operation called Complete message as a built-in connector. Search for the action and click on this operation to add the action to your design surface. Provide: Delivery tag Consumer tag Acknowledgment (Complete or Reject) You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. You can also create queues as well, with the Create a queue action. Please see the following video with further details on the configuration of this connector: Supported Regions We are rolling out this connector worldwide, with some regions receiving it before others.Support RTL Languages on MacOS
As now, It seems Microsoft teams on MacOS does not support RTL languages when texts are being typed. This makes bad feeling when users want to read the text they've typed. The issue becomes worst when the text contains English phrase (when the message is sent) As far as I remember, Skype did support RTL languages when the texts are being typed.
How to embed large text blocks in a chat message
I am trying to include a large-ish code snippet in a Teams message. I understand that the message itself can only be so many characters, but is there a way to create an ad-hoc object to place a larger text chunk in, rather than save my content to a file and attach the file?Teams Support for Emojis in Chat and Channels Section Names
Teams users can use emojis to create or rename chat section names. By incorporating emojis into section names, users create “visual anchors” to help navigate through Teams chats and channels. Sprinkling emojis around section names doesn’t really make me navigate any smarter, but it’s a feature that Slack has, so Teams can’t be left behind in the pretty interface stakes. https://office365itpros.com/2025/10/08/teams-chat-section-names/
