Access begins rollout of Big Forms for Modern Monitors feature
We're excited to announce that support for large-sized forms is now available in Beta for Microsoft Access. This long-requested feature removes the longstanding 22-inch form size limitation and lays the foundation for a more modern, scalable, and accessible form experience. It's one of the most highly requested enhancements from the Access community and a top-voted request on the Access feedback forum. This feature is in Beta now and expected to be in the Current Channel preview by July 21st, 2026. Why we're making this change When Access was originally designed, form dimensions were constrained by underlying technology that effectively limited forms to approximately 22 inches in width or height. As monitor resolutions increased and ultrawide displays became common, that limitation became increasingly restrictive. Developers were forced to design for the lowest common denominator screen size, even when their users had significantly more screen real estate available. The result? Complex business applications often required excessive scrolling, crowded interfaces, or compromises in design. With this Beta release, Access developers can now create forms that take full advantage of today's larger monitors and higher resolutions. What's changing The 22-inch limit is gone. The primary enhancement is simple but powerful: Forms can now exceed the previous 22-inch size limitation. Controls can be placed beyond the historical boundary. Form sections can be designed at much larger dimensions. Developers can create richer and more detailed business applications. For customers building dashboards, operational workspaces, inventory systems, CRM solutions, or other complex applications, this means more content can be displayed simultaneously without forcing users to navigate between multiple forms. Designed for modern workspaces Large monitors have transformed the way people work. Many customers now use: Dual-monitor setups Ultrawide displays High-resolution 4K monitors Vertical monitors for specialized workflows This feature allows Access applications to better leverage those environments. Developers are no longer forced to design around constraints that originated more than 20 years ago. As a result, users can: View more information at once Reduce unnecessary scrolling Create more sophisticated layouts Improve efficiency during data entry and review tasks Accessibility benefits Although the primary audience for this feature is Access developers and users working with larger displays, removing the size limitation also delivers important accessibility benefits. Larger form designs allow more flexibility in presenting information, increasing spacing between controls, displaying larger text, and reducing visual clutter. These improvements can make applications easier to use for customers with low vision and others who benefit from magnified content. We hope you enjoy this improvement and as always, look forward to your comments. (Thank you to MVP Colin Riddington for the thumbnail image.)
My Journey with Azure SRE Agent
Introduction A customer came to me with a problem that many organisations have. They control their infrastructure through Infrastructure as Code, but there are often scenarios where an admin needs to go in and make a change - even though they would ideally not want this to happen. The use an Entra feature Privileged Identity Management (PIM). Users statically don't have contributor access to Azure resources, but PIM allows them to elevate their access for a period of time. As part of PIM, the admin needs to give a reason for the elevation. Wouldn't it be good if an agent of some sort could look at this reason, then look at what the user actually did and make an assessment on whether what they did aligned with the reason given? Then alert if not. I initially built Python agents to handle this, but as with many "build vs. buy" decisions, I eventually discovered that Azure SRE Agent (in preview at the time of writing) could do what I needed – and more. This blog chronicles my journey from initial scepticism to building a fully autonomous PIM elevation audit agent. Along the way, I learned valuable lessons about what SRE Agent is designed for, how to work with its tooling model, and the difference between interactive exploration and production automation. The Starting Point: Python Agents and the Buy vs. Build Decision Before discovering SRE Agent, I had functional Python scripts that queried Azure Audit Logs and Activity Logs to correlate PIM activations with actual Azure operations. They worked, but they required maintenance, error handling, scheduling infrastructure, and ongoing attention. When I heard about Azure SRE Agent's capabilities as an autonomous monitoring platform, I decided to investigate. The decision: If there's a choice between buy versus build, buy should win – especially when the "buy" option is a managed Azure service with built-in security, monitoring, and integration capabilities. First Impressions: The Interactive Front End One of the first features that caught my attention was SRE Agent's chat interface. Unlike my static Python scripts, I could have conversational interactions with the agent, refining queries and exploring my Azure environment in natural language. This was powerful for discovery and prototyping. Initial Success (and Failure) When I first asked SRE Agent to analyse PIM elevation patterns, the results were... disappointing. The agent couldn't initially answer my PIM elevation questions effectively. However, this is where the interactive experience shone: through. With coaching in an interactive session, I could: - Explain what PIM activation events look like in Azure Audit Logs - Show the agent how to correlate `CorrelationId` between activation requests and justifications - Demonstrate how to build time windows from activation start to deactivation/expiration - Guide it through matching Azure Activity operations against justification keywords After several rounds of refinement, the agent eventually got excellent results. The interactive session wasn't just a chatbot – it was a learning tool that helped me shape the agent's behaviour. The Subagent Puzzle: Interactive vs. Headless What I really needed was an autonomous agent that could run on a schedule. As I got better results from the interactive sessions, Subagents is the tool in SRE Agent for this. I naturally wanted to convert the interactive session into a subagent that could run autonomously. This is where I hit my first conceptual stumbling block. The Aha Moment: Understanding SRE Agent's Purpose I was initially confused about how to structure a subagent. Should it replicate the interactive conversation flow? How do I capture all that back-and-forth in a static configuration? After discussions with the engineering, I learned a critical lesson: The interactive experience is fantastic for exploration, prototyping, and troubleshooting – but it's not what you should be aiming for in production automation. This reframed my entire approach. Instead of trying to replicate the conversational flow, I needed to distil my learnings from those sessions into the instructions for a subagent. Struggling with Subagent Format Even with this clarity, I struggled with the format of a subagent definition. The YAML structure, the `system_prompt` verbosity, the tool declarations – it felt overwhelming to translate my interactive sessions into a configuration file. The Game-Changer: Let the Agent Write Itself Then came the game-changing advice from engineering: This was brilliant in its simplicity. I had already what I wanted the agent to do in the interactive chat session. It was a simple as "generate a subagent from this conversation". I must admit, I did have to ask it to generate an email with the report, but the bulk of the effort in generating the YAML subagent file was done by the agent. What would have taken me hours of trial and error was done in minutes. Tool Configuration: The Missing Pieces With a subagent definition in hand, I deployed it and... nothing worked. This began the most educational part of my journey: understanding how tools work in Azure SRE Agent. Challenge #1: Accessing Log Analytics My subagent kept failing to query Log Analytics. I initially thought this was a role assignment issue – did the agent's managed identity have Log Analytics Reader permissions? I spent time checking RBAC, verifying workspace access, and reviewing Entra ID permissions. The real issue? I needed to add `QueryLogAnalyticsByWorkspaceId` as a tool in my subagent configuration! tools: - QueryLogAnalyticsByWorkspaceId The Azure SRE Agent UI supports selecting this tool during configuration, but I had missed it. More importantly, I needed to mention the Log Analytics workspace ID in my subagent's `system_prompt` so the agent knew which workspace to target: system_prompt: > ... Query the workspace: XXXXXX-d119-4550-86c0-YYYYYYYYYYY... Lesson learned: Tools aren't automatically available – you must explicitly declare them. The agent uses this to understand what capabilities it has and to configure the appropriate authentication and access patterns. Challenge #2: Sending Email Notifications The next hurdle was sending email reports. My PIM audit was working beautifully, but the results were only visible in logs. I needed email notifications. Initially, there didn't seem to be a built-in email tool I could choose from the portal. I attempted to write a custom Python tool that sent emails via Microsoft Graph API. This seemed logical – I'd done this in my previous Python agents. Problem: Corporate email policies blocked my application from sending emails via Graph. This was a security feature, not a bug, but it meant my custom tool approach was dead in the water. Discovering the Outlook Connector Then I noticed the Outlook connector in the SRE Agent configuration portal. This was a managed connector specifically for sending emails with pre-configured authentication. I set it up, configured it (noting the connector ID: `connector-abf2`), and waited for emails. Still nothing. The Manual YAML Edit Trawling through other sample subagent configurations, I discovered a tool called SendOutlookEmail. This tool wasn't available in the portal's dropdown menu, but it existed in the platform. I needed to **manually add this to my subagent YAML file**: tools: - QueryLogAnalyticsByWorkspaceId - SendOutlookEmail After this change and redeploying the subagent, emails started flowing perfectly. Lesson learned: The portal UI is evolving (remember, this is preview), and not all tools are exposed visually yet. Don't be afraid to hand-edit the YAML when you know a capability exists. The documentation and sample repositories are your friends. Making It Fully Autonomous: Scheduled Triggers With a working subagent that could query logs, analyse alignment, and send emails, I had one final step: scheduling it. I created a scheduled task trigger in Azure SRE Agent configured to run every 24 hours (UTC). This trigger invokes my PIM elevation subagent, which executes its entire workflow autonomously and emails stakeholders with any findings. The subagent configuration includes this execution schedule guidance: system_prompt: > Execution schedule: Run every 24h (UTC). Now, every morning, our security team receives a PIM elevation alignment report without any manual intervention. The Result: A Production PIM Elevation Agent My final solution is an **autonomous agent** that: Runs on a 24-hour schedule Queries Azure Audit Logs for PIM activations Extracts user justifications from the log Builds precise activation time windows Queries Azure Activity logs during that time window Classifies alignment: Aligned, Partial, or NotAligned Generates JSON and plaintext reports Emails stakeholders with flagged non-aligned activity No Python scripts. No custom authentication handling. No infrastructure to maintain. You can see the full subagent configuration in my GitHub repository: PIM Elevation Agent Reflections: SRE Agent's Power and Rough Edges Azure SRE Agent is powerful. The ability to define complex audit workflows in declarative YAML, leverage natural language prompts for behaviour specification, and integrate with Azure services through managed tools is genuinely impressive. It also integrates with incident response services - both being able to generate incidents and to trigger flows from incidents. All as a first-class Azure Platform as a Service (PaaS). However, it's important to remember that this is a preview service (as of February 2026). There are rough edges: - Tool discoverability: Not all tools are visible in the portal UI - Documentation gaps: Some capabilities require digging through samples - Learning curve: Understanding the interactive-vs-headless paradigm takes time - Debugging: Error messages aren't always clear about what's misconfigured These are typical preview-stage challenges, and I expect they'll improve as the service matures. The core platform is solid, and the engineering team is responsive to feedback. Key Takeaways If you're considering Azure SRE Agent, here are my lessons learned: Use interactive sessions for discovery – They're excellent for prototyping and learning Think headless/autonomous for production – Autonomous agents should be declarative, not conversational Let the agent write itself – Ask the interactive session to generate subagent configs Explicitly declare tools – They're not automatic; you must add them to your config Include context in prompts – Workspace IDs, connector IDs, schedules – be specific Don't fear manual YAML edits – The portal is evolving, hand-editing is ok Check samples and docs*– Other configurations show patterns and tools not yet in UI, so check the YAML of these Embrace "buy over build" – Managed services reduce long-term maintenance burden Resources: - SRE Agent Documentation - my PIM Elevation subagent sample - Kusto (KQL) Query Reference *This blog post represents my personal experience and opinions. Azure SRE Agent capabilities and UI may have changed since the time of writing.*
Getting data from Snowflake to Excel
Hello I have multiple no technical users and am trying to find a way to setup a snowflake query for them and then let them refresh it whenever they want or on a schedule, but I couldn't find a good solution this what i found so far: ODBC (Not great for non technical users needs setup on each user desktop) Power Automate (Needs Power Automate Premium which we don't have) Third Party tools (Expensive pricing models) Through Power BI (We want to separate this process from power bi) Any suggested solution please!MCP for Beginners: Why Every AI Engineer and Developer Should Learn the Model Context Protocol
If you have spent any time building with large language models in the last year, you have hit the same wall everyone hits: your model is brilliant at reasoning but blind to the real world. It cannot read your database, call your internal API, search your documents, or trigger a deployment unless you hand-write glue code for every single integration. The Model Context Protocol (MCP) exists to tear that wall down, and Microsoft's open-source MCP for Beginners curriculum (reachable via the short link https://aka.ms/mcp-for-beginners) is the most complete, hands-on way to learn it. This post explains what MCP is, walks through the latest updates to the course, shows real code, and makes the case for why MCP belongs on your learning roadmap right now. Whether you are an AI engineer shipping agents to production, a developer wiring tools into Copilot, or a student trying to build a standout portfolio project. What is MCP, and why does it matter? Think of MCP as a universal translator for AI applications. Just as a USB-C port lets you connect any peripheral to any laptop without a custom cable per device, MCP lets an AI model connect to any tool or data source through one standardized protocol. The course uses exactly this analogy, and it holds up well. Before MCP, integrations were an M × N problem: every one of your M AI applications needed bespoke code to talk to each of your N tools. MCP turns that into an M + N problem. Build a tool once as an MCP server, and any MCP-compatible client, Claude Desktop, VS Code, Cursor, GitHub Copilot, and many others — can use it immediately. The protocol is built on a clean client–server model with a small set of primitives: Tools — functions the model can call (query a database, send an email, run code). Resources — data the server exposes for context (files, records, documents). Prompts — reusable, parameterized prompt templates. Sampling — a server asking the client's LLM to generate a completion, enabling collaborative workflows. Elicitation — a server requesting structured input from the user mid-task. Roots — boundaries that tell a server which directories or resources it is allowed to operate on. Communication runs over JSON-RPC, with transports for local processes ( stdio ) and remote servers (streamable HTTP). That standardization is the whole point: write to the spec, and you interoperate with the entire ecosystem. What's new: the latest updates to the course The MCP for Beginners curriculum is actively maintained, and the public changelog reads like a release log for a living product. Here are the most important recent changes, drawn directly from that changelog. 1. Aligned to MCP Specification The biggest update: the entire curriculum has been validated against the current MCP Specification 2025-11-25 and the latest official SDKs. Stale references to older spec revisions (2025-03-26 and 2025-06-18) were corrected across the security, transport, real-time search, sampling, and stdio-server modules, with links repointed to the canonical modelcontextprotocol.io spec paths. A gap analysis confirmed the course already covers every primitive introduced or expanded in the latest spec: Sampling — covered in lesson 3.14 and Advanced Topics. Elicitation (including URL mode) — in Core Concepts and Protocol Features. Roots — in the Introduction, Core Concepts, and Root Contexts. Tasks (experimental, long-running operations) — in Core Concepts and Protocol Features. Tool Annotations ( readOnlyHint / destructiveHint ) — in Core Concepts and Protocol Features. 2. Samples validated against current SDKs Code that does not run is worse than no code at all, so the maintainers re-validated the core samples: TypeScript: @modelcontextprotocol/sdk resolved to 1.29.0 ; a tsc --noEmit type-check passed with no errors — the McpServer and StdioServerTransport APIs remain valid. Python: validated in an isolated virtual environment with mcp[cli] (1.27.2); FastMCP.list_tools() correctly returned the sample add and subtract tools. SDK version pins across labs were bumped (for example mcp>=1.26.0 ) and lockfiles regenerated so every sample tracks the current release. 3. A serious security pass Security is treated as a first-class concern, not an afterthought. A full audit across every dependency manifest and the sample source code was run, and npm audit now reports 0 vulnerabilities in every audited directory. Highlights: Transitive npm advisories (in the MCP Inspector dev tool, the OpenAI client, and the SDK) were remediated by bumping @modelcontextprotocol/inspector to 0.22.0 and pinning a patched shell-quote . A real code-level command-injection fix (OWASP A03): an open_in_vscode tool that used subprocess.run(..., shell=True) was rewritten to launch the resolved executable directly with no shell — closing a metacharacter-injection vector. Python dependencies were audited with pip-audit , and a vulnerable transitive werkzeug was pinned to a patched >=3.1.6 . For anyone learning to ship agents, this is gold: the course demonstrates the whole secure-development loop, not just the happy path. 4. New lessons and a growing curriculum The curriculum keeps expanding with practical, modern lessons: 5.17 Adversarial Multi-Agent Reasoning — two agents argue opposite sides of a question using shared MCP tools ( web_search + run_python ), judged by a third agent. Includes a Mermaid architecture diagram, orchestrators in Python, TypeScript, and C#, and use cases like hallucination detection, threat modeling, and API design review. 3.12 MCP Hosts — configuration for Claude Desktop, VS Code, Cursor, Cline, and Windsurf, with JSON templates and a transport comparison table. 3.13 MCP Inspector — a debugging guide for testing tools, resources, and prompts. 4.1 Pagination — cursor-based pagination patterns in Python, TypeScript, and Java. 5.16 Protocol Features — progress notifications, request cancellation, resource templates, and lifecycle management. 5. Microsoft product rebranding Content was updated to reflect Microsoft's rebranding: Azure AI Foundry → Microsoft Foundry, and the AI Toolkit (AITK) → Microsoft Foundry Toolkit Extension for VS Code. If you have seen older tutorials referencing the previous names, the curriculum is now current. Your first MCP server: see how little code it takes The course's "first server" lesson builds a simple calculator. Here is the shape of a minimal MCP server in Python using FastMCP , which mirrors the validated sample in the repo. Notice how the protocol plumbing disappears — you just decorate functions. # server.py — a minimal MCP server with two tools from mcp.server.fastmcp import FastMCP # Name your server; this identifies it to MCP clients mcp = FastMCP("Calculator") @mcp.tool() def add(a: int, b: int) -> int: """Add two numbers and return the result.""" return a + b @mcp.tool() def subtract(a: int, b: int) -> int: """Subtract b from a and return the result.""" return a - b if __name__ == "__main__": # Run over stdio so local hosts (VS Code, Claude Desktop) can connect mcp.run() The same idea in TypeScript, using the official SDK validated at version 1.29.0 : // server.ts — minimal MCP server in TypeScript import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod"; const server = new McpServer({ name: "Calculator", version: "1.0.0" }); // Register a tool with a typed input schema server.tool( "add", { a: z.number(), b: z.number() }, async ({ a, b }) => ({ content: [{ type: "text", text: String(a + b) }], }) ); // Connect over stdio and start listening const transport = new StdioServerTransport(); await server.connect(transport); That is a complete, runnable server. The docstrings and schemas matter: MCP exposes them to the model so it knows when and how to call each tool. Clear descriptions are effectively prompt engineering for your tools — a common pitfall is leaving them vague, which leads to the model misusing or ignoring the tool. Connecting it in VS Code Once your server runs, an MCP host connects to it. A typical VS Code / host configuration looks like this: { "servers": { "calculator": { "command": "python", "args": ["server.py"] } } } Lesson 3.12 (MCP Hosts) covers the equivalent JSON for Claude Desktop, Cursor, Cline, and Windsurf, and lesson 3.13 shows how to use the MCP Inspector to test your tools before wiring them into a host — the single best debugging habit you can build early. How the course is structured The curriculum is organized as a progressive journey with hands-on code in C#, Java, JavaScript, Python, Rust, and TypeScript. It is grouped into phases: Foundations (Modules 0–2): Introduction, Core Concepts, and Security. Building (Module 3): Getting Started — 15 lessons covering your first server and client, LLM clients, VS Code integration, stdio and HTTP streaming, testing, deployment, auth, hosts, the Inspector, sampling, and MCP Apps. Growing (Modules 4–5): Practical Implementation and Advanced Topics — 17 advanced lessons including Azure integration, OAuth2, Entra ID auth, scaling, multi-modality, context engineering, custom transports, and adversarial multi-agent reasoning. Mastery (Modules 6–11): Community Contributions, Lessons from Early Adoption, Best Practices, Case Studies, a Microsoft Foundry Toolkit workshop, and an end-to-end 13-lab PostgreSQL capstone. That final module is the standout for portfolio building: a complete, production-flavored path that takes you from architecture and row-level security through database design, a FastMCP server, semantic search with pgvector and Azure OpenAI, testing, Docker deployment to Azure Container Apps, and monitoring with Application Insights. Why developers should learn MCP now For AI engineers MCP is becoming the default integration layer for agents. Instead of re-implementing tool calling for every framework, you write to one open protocol and your tools work everywhere. The advanced modules — sampling, roots, elicitation, scaling, routing, and adversarial multi-agent patterns — are exactly the techniques you need to move agents from demo to production. For developers MCP is already wired into tools you use daily: VS Code, GitHub Copilot, Claude Desktop, Cursor, and more. Learning to build an MCP server means you can expose your systems — internal APIs, databases, CI/CD — to AI assistants safely. The security-first approach in the course (OAuth2, Entra ID, RBAC, dependency auditing) teaches you to do this the right way from day one. For students MCP is a rare opportunity to learn a technology while it is still early, with a free, beginner-friendly, Microsoft-maintained curriculum and code in six languages. The 13-lab capstone alone is a genuine portfolio project. And with content translated into 50+ languages, the barrier to entry is low no matter where you are. Responsible and secure by design A recurring theme worth calling out: the course does not treat security and governance as optional extras. It models real practices you should carry into your own work: Least privilege via roots — constrain what a server can touch. Tool annotations — mark tools readOnlyHint or destructiveHint so clients can warn users before destructive actions. No shells for user input — the command-injection fix is a textbook example of why you never pass untrusted input through a shell. Dependency hygiene — audit with npm audit and pip-audit , and pin patched releases. Proper auth — dedicated lessons on OAuth2 and Microsoft Entra ID. Key takeaways MCP standardizes how AI connects to tools and data, turning a combinatorial integration problem into a simple, reusable one. The course is current, validated against MCP Specification 2025-11-25 with SDKs at TypeScript 1.29.0 and Python mcp 1.27.2 . Samples actually run, and the repo demonstrates a full secure-development loop with 0 reported vulnerabilities after auditing. It is broad and deep: from a 10-line calculator server to a 13-lab production capstone, in six languages. It is the fastest credible path to MCP fluency for AI engineers, developers, and students alike. Get started today Open the course: https://aka.ms/mcp-for-beginners (redirects to the GitHub repository). Fork and clone it — use a sparse checkout to skip translations for a faster download: git clone --filter=blob:none --sparse https://github.com/microsoft/mcp-for-beginners.git cd mcp-for-beginners git sparse-checkout set --no-cone "/*" "!translations" "!translated_images" Build your first server with lesson 3.1 in your language of choice. Debug it with the MCP Inspector, then connect it in VS Code. Go deep with the 13-lab database capstone, and read the official spec at modelcontextprotocol.io. Track what's new in the changelog and join the community discussions. MCP is quietly becoming the connective tissue of the AI ecosystem. The earlier you learn it, the more leverage you will have — and Microsoft's MCP for Beginners is the clearest on-ramp available. Star the repo, build a server this week, and start connecting your AI to the world.Dragon Copilot and Microsoft Marketplace are transforming the way healthcare is delivered
If AI has so much promise in healthcare, why does it still feel so hard to apply in everyday workflows? That question is starting to shape much of the conversation across the industry. Healthcare teams aren’t debating whether AI matters anymore, they’re focused on how to make it work in environments that are already stretched thin. Reality: Healthcare has a capacity problem Healthcare isn’t dealing with a demand problem; it’s dealing with a capacity constraint. In fact, 79% of healthcare workers say they don’t have enough time or energy to do their work, 51% of healthcare leaders say productivity needs to increase, and 79% are confident AI will play a role in expanding organizational capacity. That pressure shows up everywhere: in documentation backlogs, fragmented and click-heavy workflows, administrative overload, and ultimately less time spent with patients. This is where the conversation around AI is shifting; not toward adding more tools but toward removing friction from the workflows that already exist and helping care teams move faster with less overhead inside the flow of care. That reality came through clearly during a recent Microsoft Marketplace Customer Office Hour on Dragon Copilot and Microsoft Marketplace: how to operationalize AI within real-world clinical workflows and enterprise healthcare environments that are experiencing a capacity problem. Instead of focusing on future-state possibilities, the conversation centered on what it takes to move from promise to practice, and where AI can start delivering value today. That distinction matters because developers, healthcare architects, and AI engineers are no longer asking whether AI can create value. The industry has largely accepted that it will play a meaningful role across healthcare. The real challenge is how to integrate into environments already burdened by operational complexity, fragmented workflows, regulatory pressures, and disconnected technologies. In practice, most healthcare organizations aren’t lacking data or systems, they’re struggling with how those systems work together. Clinicians and administrative teams operate across EHRs, reimbursement platforms, documentation tools, referral systems, messaging apps, and care coordination workflows that often function in isolation. Each additional screen, handoff, or disconnected experience introduces friction, and over time that friction compounds into inefficiencies that impact clinicians, administrators, and ultimately patients. This is why AI cannot simply sit on top of existing systems as another productivity layer; it needs to act as an orchestration layer that reduces complexity directly within the flow of care. That shift fundamentally changes how we think about healthcare AI, moving from isolated features to embedded intelligence that supports the workflows where care teams already spend their time. Dragon Copilot as a clinical workflow platform Dragon Copilot is not positioned as just another ambient listening tool or conversational assistant. It's designed as a clinical workflow platform that integrates into how care is delivered. While voice capabilities like ambient listening and natural language interaction are foundational, the real value comes from combining contextual intelligence, workflow automation, and extensibility. In practice, that means clinicians can access relevant information directly within their workflow, reduce fragmentation across systems, and act using natural language without constantly switching between tools. Extending healthcare AI through Microsoft Marketplace What makes this even more compelling is how Dragon Copilot extends through AI apps and agents connected via Microsoft Marketplace. This shifts the conversation from a single AI solution to a broader ecosystem approach. Instead of relying on monolithic systems to solve every problem, healthcare organizations can layer specialized AI capabilities directly into their workflows. During the session, we walked through examples like coding and charge capture, denial prevention, eligibility verification, medication safety checks, and patient education each addressing a specific operational need without requiring organizations to replace core systems. From a technical perspective, what stands out is not just automation, but the ability to reduce workflow re-entry and repetitive administrative loops. Today, many processes require clinicians and administrators to document, submit, reprocess, and reconcile information across disconnected systems. By embedding AI into those workflows, whether for coding validation, reimbursement support, or clinical guidance, organizations can streamline those cycles, improve continuity between systems, and reduce the compounding operational burden that slows teams down. What does this mean for healthcare developers For developers building healthcare solutions, this shift opens meaningful opportunities across workflow orchestration, AI-assisted compliance, operational intelligence, policy validation, and real-time financial support. More importantly, it reflects a broader architectural change in how healthcare technology is evolving. Rather than attempting to replace existing systems, the industry is moving toward connected AI services that extend and augment what’s already in place. This approach matters because healthcare organizations rarely overhaul core infrastructure all at once. Instead, they evolve incrementally by layering new capabilities into existing workflows. Dragon Copilot, combined with Microsoft Marketplace, is designed to support that model. AI agents can surface insights, automate repetitive tasks, and support decision-making while staying embedded within established clinical environments, helping developers build solutions that are practical, scalable, and aligned with how healthcare systems actually operate today. The strategic value of ecosystem extensibility As the importance of ecosystem extensibility continues to grow, Microsoft is intentionally building beyond a standalone healthcare AI solution. Instead, the focus is on creating an ecosystem that enables connected intelligence across clinical and operational workflows. For developers, this shift has real implications. It directly impacts how quickly solutions can be built, how easily they can be deployed, and how far innovation can scale. Without extensibility, progress is constrained by the roadmap of a single platform. With it, developers and healthcare technology providers can target highly specific workflow gaps with purpose-built solutions. That opens the door to a new class of innovations from AI agents and workflow accelerators to embedded clinical decision support and healthcare-specific automation designed to fit seamlessly into existing environments and address the nuanced needs of modern care delivery. Reducing adoption friction in enterprise healthcare The Marketplace component of this strategy directly addresses some of the most persistent barriers to adoption in enterprise healthcare. Organizations can simplify procurement, reduce vendor onboarding friction, streamline licensing, and consolidate billing through Microsoft’s existing purchasing infrastructure. From a developer and software company perspective, this is significant because historically the challenge in healthcare hasn’t been building new capabilities but getting them adopted and scaled in complex environments. By reducing the effort required to evaluate, purchase, deploy, and operationalize AI solutions, Marketplace changes the pace at which organizations can move from experimentation to real-world implementation. That efficiency becomes critical as healthcare shifts from isolated pilots to production-scale deployments, where speed, integration, and operational alignment ultimately determine whether AI delivers meaningful impact. From AI experimentation to production-ready workflows Healthcare AI is no longer confined to pilots or conceptual experimentation. Organizations are now evaluating production-ready solutions that can integrate directly into enterprise workflows. That shift brings a different set of expectations for developers and architects. Instead of asking whether AI can generate useful outputs, the focus has moved to operational questions: Can these systems integrate seamlessly into clinician workflows? Will they reduce complexity without introducing disruption? Can they scale reliably, perform consistently, and meet regulatory requirements? These are not just AI challenges, they’re deeply rooted in systems integration, workflow design, operational engineering, and enterprise architecture. Success depends not only on model performance, but on how well AI fits into the realities of healthcare delivery, supports care teams in context, and operates within the constraints of highly regulated, mission-critical environments. Designing for operational value, not just model innovation This is exactly why the conversation matters for the healthcare developer community right now. Future success in healthcare AI will depend less on model novelty and more on how well those models integrate into real workflows. Most healthcare organizations are already navigating fragmented environments filled with disconnected systems, and the solutions that deliver lasting value will be the ones that reduce cognitive load, minimize context switching, surface information at the right moment, and integrate naturally into day-to-day clinical work. In that sense, the challenge becomes less about AI in isolation and more about systems design. Meaningful progress won’t come from standalone copilots operating outside enterprise infrastructure. It will come from connected ecosystems where AI services, workflow accelerators, and operational tools work together seamlessly. That’s how intelligent healthcare workflows take shape: not as a single application, but as a coordinated system designed around how care is actually delivered. Why this direction matters for the developer ecosystem Dragon Copilot is emerging not just as a healthcare AI experience, but as a platform that brings together workflow intelligence and ecosystem extensibility. By connecting directly into operational healthcare workflows and enabling integration through Microsoft Marketplace, it creates new opportunities for healthcare developers, enterprise architects, and workflow automation providers to build solutions that are both targeted and scalable. While the ecosystem is still evolving, the strategic direction is becoming increasingly clear: AI agents and connected applications are moving closer to the workflow layer itself. In healthcare, that proximity matters. The solutions that integrate most naturally into day-to-day operations, rather than existing alongside them, are the ones most likely to drive meaningful adoption and long-term impact. Watch the full session For organizations building healthcare software, enterprise AI systems, workflow automation platforms, or operational healthcare technologies, the Microsoft Marketplace Customer Office Hour session provides valuable insight into how Microsoft is approaching healthcare AI at ecosystem scale. 👉 Learn more and watch the full session here: Healthcare innovation with Dragon Copilot and Microsoft Marketplace Additional Resources You can learn more through Microsoft Marketplace, the Marketplace Customer Office Hours series, the Microsoft Marketplace Community, and the Dragon Copilot apps and agents resources.Clarity at every stage: App Advisor turns Marketplace complexity into action
For software development companies, the Microsoft Marketplace journey isn’t always linear. It’s a series of decisions: what to build, how to package it, how to publish, and how to sell it, each with real dependencies and real friction.
URGENT: Tenant Linked & New Licenses Active, Need Manual Sync Triggered (Ticket #2606160040010375)
Hello Community Managers and Microsoft Moderators, I am writing to request an urgent escalation to a Data Protection and Billing Supervisor regarding our open case: TicketID#2606160040010375 for our nonprofit, R. Fathers M.A.D., Inc. Our legacy grant subscription lapsed on May 27, and we purchased our new active subscription on June 15—a lapse of exactly 19 days. Current Status: The Data Protection Team has successfully linked our accounts. Our new June 15 subscription is confirmed Active in our Billing dashboard. All new licenses have been successfully assigned to our active users. Frontline support ran an eDiscovery search that came back empty because the metadata indexing pointers were severed during the grant decommissioning. Because we acted within the initial 30-day window, our data sits well within the 90-day retention threshold. We have completed 100% of the front-end setup steps on our end. We need a Community Manager to internally flag TicketID#2606160040010375 so a Tier-3 engineer can manually trigger the backend data re-index. This will reconnect our intact SharePoint and OneDrive files to our newly mapped user profiles. Our nonprofit operations are completely halted until this sync is pushed. Thank you for your immediate help.Access VBA performance dramatically slowed since June Update
We are running an access based application with a large vba project. One customer with four different instances of this project experience extreme slow down in performance on all instances during the last week. We made no changes. The Microsoft Office Update was applied automatically. We believe the problem happened then. We have tried reverting to several different previous versions of Office but symptoms still remain.
