Messaging Connect: Global SMS Coverage Now Available in Azure Communication Services
Messaging Connect is now in public preview—Messaging Connect is a new partner-based model for Azure Communication Services that enables global SMS coverage in over 190 countries—starting with Infobip. It simplifies compliant delivery, removes provisioning complexity, and helps developers reach users or Agents reach humans, worldwide using the Azure Communication Service SMS API they already know.
Azure Communication Services technical documentation table of contents update
Technical documentation is like a map for using a platform—whether you're building services, solving problems, or learning new features, great documentation shows you the way to the solution you need. But what good is a map if it’s hard to read or confusing to follow? That’s why easy-to-navigate documentation is so important. It saves time, reduces frustration, and helps users focus on what they want to achieve. Azure Communication Services is a powerful platform, and powerful platforms require great documentation for both new and experienced developers. Our customers tell us consistently that our docs are a crucial part of their experience of using our platform. Some studies suggest that documentation and samples are the most important elements of a great developer experience. In this update, we’re excited to share how we’ve improved our technical documentation’s navigation to make it quicker and simpler than ever to find the information you need when you need it. Why did we change? In order for our content to be useful to you, it first needs to be findable. When we launched Azure Communication Services, the small number of articles on our site made it easy to navigate and find relevant content. As we’ve grown, though, our content became harder to find for users due to the quantity of articles they need to navigate. To refresh your memory, the table of contents on our docs site used to be structured with these base categories: Overview Quickstart Tutorials Samples Concepts Resources References These directory names describ e the type of content they contain. This structure is a very useful model for products with a clearly-defined set of use cases, where typically a customer’s job-to-be-done is more constrained, but it breaks down when used for complex, powerful platforms that support a broad range of use cases in the way that Azure Communication Services does. We tried a number of small-scale changes to address the problems people were having on our site, such as having certain directories default to open on page load, but as the site grew, we became concerned that our site navigation model was becoming confusing to users and having a negative impact on their experience with our product. We decided to test that hypothesis and consider different structures that might serve our content and our customers better. Our user research team interviewed 18 customers with varying levels of experience on our platform. The research uncovered several problems that customers were having with the way our docs navigation was structured. From confusing folder titles, to related topics being far away from each other in the nav model, to general confusion around what folder titles meant, to problems finding some of the most basic information about using our platform, and a host of other issues, our user research made it clear to us that we had a problem that we needed to fix for our users. What did we change in this release? To help address these issues, we made a few key changes to make our table of contents simpler and easier to navigate. The changes we made were strictly to site navigation, not page content, and they include: We've restructured the root-level navigation to be focused on communication modality and feature type, rather than content type, to better model our customers' jobs-to-be-done. Topics include All supported communication channels Horizontal features that span more than one channel Topics of special interest to our customers, like AI Basic needs, like troubleshooting and support This will allow customers to more easily find the content they need by focusing on the job they need to do, rather than on the content type. We've simplified the overview and fundamentals sections to make the site less overwhelming on first load. We've surfaced features that customers told us were difficult to find, such as UI Library, Teams interop, and Job router. We've organized the content within each directory to roughly follow a beginner->expert path to make content more linear, and to make it easier for a user to find the next step in completing their task. We've removed unnecessary layers in our nav, making content easier to find. We've added a link to pricing information to each primitive to address a common customer complaint, that pricing information is difficult to find and understand. We've combined quickstarts, samples, and tutorials into one directory per primitive, called "Samples and tutorials", to address a customer complaint that our category names were confusing. We added a directory to each primitive for Resources, to keep important information close by. We added root-level directories for Common Scenarios, Troubleshooting, and Help and support. We did a full pass across all TOC entries to ensure correct casing, and edited entries for readability and consistency with page content, as well as for length to adhere to Microsoft guidelines and improve readability. These changes have led us to a structure that we feel less taxing for the reader, especially on first visit, maps more closely to the customer’s mental model of the information by focusing on the job-to-be-done rather than content type, helps lead them through the content from easiest to hardest, helps make it easier for them to find the information they need when they need it, and helps remind them of all the different features we support. Here’s what the table of contents looks like on page load as of Feb 6: These changes are live now. You can see them on the Azure Communication Services Technical documentation site. What’s next: In the coming weeks we will continue to make refinements based on customer feedback and our assessment of usage metrics. Our content team will begin updating article content to improve readability and enhance learning. We will be monitoring our changes and seeking your feedback. How will we monitor the effectiveness of our changes? To track the effectiveness of our changes and to be sure we haven’t regressed, we’ll be tracking a few key metrics Bounce rates: We’ll be on the lookout for an increase in bounce rates, which would indicate that customers are frequently landing on pages that don’t meet their expectations. Page Views: We’ll be tracking the number of page views for our most-visited pages across different features. A decrease in page views for these pages will be an indicator that customers are not able to find pages that had previously been popular. Customer Interviews: We will be reaching out to some of you to get your impressions of the new structure of our content over the coming weeks. Customer Surveys: We've created a survey that you can use to give us your feedback. We'll also be adding this link to select pages to allow you to tell us what you think of our changes while you're using them! So, give our new site navigation a try, and please don’t hesitate to share your feedback either by filling out our survey or by sending an email to acs-docs-feedback@microsoft.com. We look forward to hearing from you! ANew Storage Migration Service WAC extension 1.42.0 available
Heya folks, Ned here again. We just released an update to the Storage Migration Service extension for Windows Admin Center. It will automatically appear in your WAC feeds in the next few hours. Going forward I'm going to always announce changes to these WAC tools, since the updates don't have release notes built-in. Tool: Storage Migration Service Version 1.42.0 Notes: Now includes a link to the Azure File Sync tool for each migrated server when cutover completes. This means you can click and be sent to a new tab specific to that server and setup AFS on that node. We have a full set of integration planned here, this is just a nugget. No longer show the Azure File Sync popup banner during transfers and cutovers. Transfer and re-transfer now display more understandable messaging, buttons, and choices. Fixes to ensure accurate share inclusion when modifying a transfer mapping Accessibility fixes Thanks, and good hunting on those Windows Server 2008 machines that stop being supported in 7 months! - Ned "January 14, 2020" PyleBuilding an AI Receptionist: A Hands-On Demo with Azure Communication Services and OpenAI
Ever missed an appointment because of a rigid SMS system? What if you could text a change and get an immediate, natural response that understands your intent and confirms a new slot quickly? In this post, we'll show you how to build an AI receptionist that does just that, using Azure Communication Services and Azure OpenAI. We'll guide you through a hands-on demo that uses a simulated but realistic calendar for reliable confirmations and rescheduling, and show you how to make it production-ready. A natural text thread with the scheduling agent Watch the Walkthrough Prefer a walkthrough? Watch the video demo to see the app in action with live code explanations. This demo is ideal for anyone who wants to explore conversational AI with minimal setup -- whether you're a developer, product manager, or just curious about integrating Azure services. What Actually Happens Under the Hood Here’s the simple set of moving parts behind the “AI receptionist” feel. First a quick look at each piece, then the exact path a message takes. Core pieces we’re using for this demo: Azure Communication Services: Provides the real phone number, receives incoming text messages, and sends replies. Azure Event Grid: Immediately forwards each new message event to a public URL (the webhook) your app exposes. FastAPI: Hosts that webhook (an HTTP endpoint) and keeps simple in‑memory conversation and calendar data. Azure OpenAI: Generates the receptionist’s reply using the running conversation plus a small snapshot of available appointment times. Simulated calendar: Thirty upcoming business days with realistic fullness so the system can offer believable open slots. Then the message moves through this path: You send a text message to the demo phone number (handled by Azure Communication Services). Azure Communication Services raises a “message received” event. Azure Event Grid delivers that event as an HTTP POST to the FastAPI webhook (a regular URL). The webhook quickly returns “OK” and kicks off a background function (process_sms in main.py) so the user is never kept waiting. If this is your first message, it creates a mock appointment for “tomorrow” and sends a reminder; otherwise it adds your new message to the conversation history. It selects a few upcoming open slots from the simulated calendar, adds them to the system prompt, asks Azure OpenAI for a receptionist‑style reply, and receives the response. The reply goes back through Azure Communication Services, and the conversation state stays in memory. That’s the loop. An event arrives, flows through a thin path, and a reply goes out. No constant checking (polling) or scheduled scripts needed. Demo vs Production In the demo you start the conversation by texting the number. In a production rollout, you usually send an automated reminder (for example 24 hours before) and let the patient reply to confirm or change. From there the path is straightforward: swap the simulated calendar for a real scheduling API, persist conversation and appointment state, add authentication and signed webhook validation, and layer in logging and compliance. The event flow itself staysthe same. The Calendar Trick We prebuild the next 30 business days (weekdays only), 09:00–17:00 in 30-minute slots, mark about 80 percent as “booked,” and keep the rest “available.” On each turn we pull a small handful of near-term open times and add them to the system prompt. That gives the model concrete, bounded choices and prevents it from inventing odd times like “3:10 AM” or “Saturday 7 PM.” A single snapshot replaces custom slot logic while still feeling live. The FastAPI routes for getting calendar logic Prompt Strategy The system prompt frames a single role: a friendly receptionist limited to scheduling (no medical advice, within business hours, 30-minute increments). Each user message refreshes the availability lines so the model always sees current openings. The rules: only offer specific times when rescheduling, stay concise, and confirm final details. This balance keeps replies natural while keeping time suggestions controlled. Where to Take It Next To evolve the demo into a dependable production service you layer durability, richer scheduling logic, safety, and observability onto the same event path - no rewrite required. Productization Persist conversations and appointments (database + real scheduling/calendar API) Authentication, signed webhook validation, rate limiting Structured logging, tracing, latency and token metrics Scheduling intelligence Function / tool calls for explicit slot selection Real calendar integration (Outlook, scheduling API, electronic health record system) Time zones, appointment types, user preferences (language, time windows) Safety & context Moderation / compliance filters Retrieval for policies, preparation instructions, service types Insights & analytics Analytics (reminder → confirmation rate, response latency, fallback counts) Getting It Running (You’ll Spend Minutes, Not Hours) This setup is intentionally light. The only potentially slow step is acquiring a phone number in Azure Communication Services (see the official quickstart). Full step-by-step instructions (environment variables, dev tunnel, Event Grid subscription) live in the demo repository README. The high-level overview is: Clone the repository and copy .env.example to .env Add Azure Communication Services connection string + phone number and Azure OpenAI endpoint/key/model. Install dependencies and start the app on port 8000. Expose port 8000 with a dev tunnel and point an Event Grid SMSReceived subscription to /api/sms/webhook. Text your Azure Communication Services number and observe inbound event and reply in the terminal. Screenshot of a terminal log with inbound event + “SMS sent to ACS number" Closing You now have an event‑driven SMS conversation that feels like a live receptionist using only a phone number, a webhook, a lightweight availability snapshot, and a model prompt. Clone the repository, run the demo, and try a reschedule from your own phone. Extend it and make it your own - whether that means integrating a real scheduling API, adding persistence, or incorporating compliance features. We’d love to see what you build.
