Today we’re excited to announce the release of DCM 1.38.0!

This release includes 14 new rules; new config option to disable fixes for a particular rule; new single-line per-violation output format for Console reporter; global version constraint configuration via DCM Teams Console; support for converting fields to private named parameters for "dcm fix --type=unnecessarily-public-code" (only for Dart 3.12+); and other improvements! 🚀

Let’s go through the highlights of this release (and the full list of changes is in our changelog)!

Global Version Constraint​

While there are several options to keep the installed DCM version in sync (for example, by introducing a global configuration file with the constraint), it still remains one of the challenging parts.

That's why this release adds a new way to configure the global version constrain via the DCM Console:

This version constraint is different from the one configured via dcm_global.yaml (which needs to be configured for each project separately) and it applies to all users. If both dcm_global.yaml and this constraint are present, the latter gets the priority.

Dashboards Improvements​

Persistent Selected Intervals and Groups​

To help you keep the charts exactly as you left them, selected intervals and groups are now remembered after a page reload:

Persistent Selected Metric Segments​

And the same for selected metric segments:

Hiding Selected Categories from Charts​

To make it easier to filter out information when working with charts, charts with multiple groups/categories now support hiding selected categories by clicking on the category name:

And the same can be done with the overview pie chart:

Concise Console Output Format​

As we are continuing to improve the user experience, we are excited to introduce a new simplified output format for Console reporter!

While the old format provides all necessary information (including severity, location, description, rule name and a link to the docs), its primary downside is it makes harder to work with many issues as each console entry takes a lot of space (plus, if you are feeding the output to LLMs, it's kinda verbose).

To address that, the new concise output includes only the location and the description:

To try it out, pass --concise (or just -c) when calling any command.

Additionally, when passed to dcm run, there will be no separate sections for each command passed (e.g. Analyze results:, Unused code results:), but instead all issues will be in one sorted list:

New Config to Disabled Fixes​

To make the usage of IDE and CLI fixes even more flexible, with this release all rules now support a new config entry suggest-fixes that allows you to disable fixes on a per-rule basis.

For example,

dcm:
  rules:
    - newline-before-return:
        suggest-fixes: false

will disable fixes for newline-before-return for both dcm fix and the IDE extensions.

Auto-fixable Issues in the HTML Report​

If you prefer working with HTML reports, in this release the HTML report for dcm analyze now also includes the number of auto-fixable issues to help you know how many issues can be quickly address with running dcm fix.

New Rules​

dcm init lints-preview lib --rule-version=1.38.0  # Show rules added in 1.38.0

avoid-duplicate-factories​

Warns when a class has a factory constructor with the same implementation as another factory constructor.

This rule does not take into account parameter/factory names and other insignificant details.

For example,

class SomeClass {
  SomeClass(String data);

  factory SomeClass.fromString(String data) => SomeClass(data);
  // LINT: This factory constructor is a duplicate of SomeClass.fromString.
  //  Try removing this factory or adding unique functionality.
  factory SomeClass.parse(String data) => SomeClass(data);
}

class AnotherClass {
  AnotherClass();

  factory AnotherClass.empty() => AnotherClass();
  // LINT: This factory constructor is a duplicate of AnotherClass.empty.
  //  Try removing this factory or adding unique functionality.
  factory AnotherClass.withData(String data) => AnotherClass();
}

here, SomeClass.parse has exactly the same implementation as SomeClass.fromString and AnotherClass.withData has exactly the same implementation as AnotherClass.empty (even though the number of parameters differs, it does not affect the body of the factory constructor).

To fix the issue, try either removing the duplicate factory or changing the implementation to be unique.

This rule also comes with auto-fix.

avoid-unnecessary-factory​

Suggests converting a factory constructor to a regular constructor.

For example,

class Point {
  final double x;
  final double y;

  Point._(this.x, this.y);

  // LINT: This factory constructor can be a regular constructor.
  //  Consider converting it to a regular constructor.
  factory Point(double x, double y) {
    return Point._(x, y);
  }

  // LINT: This factory constructor can be a regular constructor.
  //  Consider converting it to a regular constructor.
  factory Point.atOrigin() => Point._(0, 0);
}

in both cases, having a factory constructor is unnecessary and only adds more code.

To fix that, use a regular constructor instead:

class Point {
  final double x;
  final double y;

  Point(this.x, this.y);

  Point.atOrigin(): x = 0, y = 0;
}

avoid-unmodified-loop-condition​

Warns when a loop condition is not modified within the loop.

For example,

void fn(String left, String right) {
  // LINT: None of the local variables in this condition are modified within the loop.
  //  Try checking for a potential mistake.
  while (left.isNotEmpty) {
    print(left);
  }
  left = '';

  // LINT: None of the local variables in this condition are modified within the loop.
  //  Try checking for a potential mistake.
  while (left != right) {
    print(left);
  }
}

here, none of the variables used in loop conditions are modified within the loop which results in an endless loop.

prefer-private-named-parameters​

Suggests using private named parameters instead of assigning to a private class field manually.

For example,

class Point {
  final double _x;

  // LINT: Prefer using private named parameters instead of assigning to the private field manually.
  Point({required double x}) : _x = x;
}

should be rewritten to

class Point {
  final double _x;

  Point({required this._x});
}

This rule also comes with auto-fix.

prefer-initializing-formals​

Suggests using initializing formal parameters when applicable.

For example,

class Some {
  final String value;
  final String another;

  const Some(String val, {required String named})
      // LINT: Use an initializing formal to assign a parameter to a field.
      //  Try using 'this.value' to initialize the field.
    : value = val,
      another = named;
}

class Another {
  final String _val;

  // LINT: Use an initializing formal to assign a parameter to a field.
  //  Try using 'this.value' to initialize the field.
  const Another(String _value) : _val = _value;
}

should be rewritten to

class Some {
  final String value;
  final String another;

  const Some(this.value, {required String named}) : another = named;
}

class Another {
  final String _val;

  const Another(this._value);
}

This rule also comes with auto-fix.

prefer-random-secure​

Warns when Random is used in a security-sensitive context.

The output of Random is predictable and must not be used in security-sensitive contexts.

This rule also comes with auto-fix.

avoid-sensitive-query-params​

Warns when a URL query string contains sensitive data.

URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources. Try passing this data via the request headers instead.

For example,

void fn() {
  // LINT: URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources.
  //  Try passing this data via the request headers.
  final url = Uri.https('api.example.com', '', {'token': 'hello'});

  // LINT: URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources.
  //  Try passing this data via the request headers.
  final hardcoded = 'https://api.example.com/user?token=test';
}

here, both URLs will end up with sensitive query parameters.

To address this issue, consider passing sensitive data via request headers or body.

avoid-unrestricted-navigation​

Warns when WebViews allow users to navigate to any URL by clicking links or through JavaScript.

Allowing unrestricted navigation within an app's WebView introduces serious security risks. For instance, malicious elements like ads can redirect users to deceptive phishing pages. Because WebViews lack standard browser safety cues (like a visible URL bar), users are more likely to trust these fake sites.

Additionally, if the WebView loads a page with a Cross-Site Scripting (XSS) vulnerability, unrestricted navigation can broaden the attack's impact. Ultimately, this loss of contextual security makes it much harder for users to spot and avoid malicious content.

For example,

void fn() {
  WebViewController()
    // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
    //  Consider preventing navigation to arbitrary URLs.
    ..setNavigationDelegate(NavigationDelegate());

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  InAppWebViewSettings();

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  InAppWebViewSettings(useShouldOverrideUrlLoading: false);

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  HeadlessInAppWebView(InAppWebViewSettings(useShouldOverrideUrlLoading: false));
}

should be rewritten to

void fn() {
  WebViewController()..setNavigationDelegate(
    NavigationDelegate(onNavigationRequest: () {
      ...
    })
  );

  InAppWebViewSettings(useShouldOverrideUrlLoading: true);

  HeadlessInAppWebView(InAppWebViewSettings(useShouldOverrideUrlLoading: true));
}

avoid-unrestricted-javascript​

Warns when JavaScript execution is enabled for WebViews.

Mobile applications using WebViews face severe risks if they render untrusted code, making them highly vulnerable to Cross-Site Scripting (XSS). Within a WebView context, malicious JavaScript can exfiltrate sensitive local files from the device. Even more critically, it can interact with exposed native application functions, potentially leading to catastrophic flaws like remote code execution.

For example,

void fn() {
  WebViewController()
    // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
    // Consider disabling JavaScript for WebViews.
    ..setJavaScriptMode(JavaScriptMode.unrestricted);

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  InAppWebViewSettings();

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  InAppWebViewSettings(javaScriptEnabled: true);

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  HeadlessInAppWebView(InAppWebViewSettings(javaScriptEnabled: true));
}

should be rewritten to

void fn() {
  WebViewController()
    ..setJavaScriptMode(JavaScriptMode.disabled);

  InAppWebViewSettings(javaScriptEnabled: false);

  HeadlessInAppWebView(InAppWebViewSettings(javaScriptEnabled: false));
}

prefer-single-notifier-per-file​

Suggests keeping only one Notifier per file.

For example,

class Some extends Notifier<int> {
  final int field = 0;

  @override
  int build() => 0;
}

// LINT: Prefer only one Notifier per file. Try moving this Notifier to a separate file.
class Another extends Notifier<int> {
  @override
  int get state;

  @override
  int build() => 0;
}

should be rewritten to

class Some extends Notifier<int> {
  final int field = 0;

  @override
  int build() => 0;
}

class Another extends Notifier<int> {
  @override
  int get state;

  @override
  int build() => 0;
}

prefer-correct-provider-file-name​

Suggests ending file names with _provider.dart for files that contain a single Provider declaration.

For example,

// LINT: File name with Providers must end with '_provider.dart'.
//  Try renaming the file.
final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

should be rewritten to

final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

prefer-riverpod-provider-suffix​

Suggests ending Provider variable names with the Provider suffix.

For example,

// LINT: The name of this provider variable should end with Provider.
//  Try renaming this variable.
final first = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

// LINT: The name of this provider variable ends with one of the banned suffixes.
//  Try renaming this variable.
final firstNotifierProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

should be rewritten to

final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

final secondProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

prefer-riverpod-notifier-suffix​

Suggests ending Notifier class names with the Notifier suffix.

For example,

// LINT: The name of this notifier class should end with Notifier.
//  Try renaming this class.
class Counter extends Notifier<int> {}

// LINT: The name of this notifier class ends with one of the banned suffixes.
//  Try renaming this class.
class CounterProviderNotifier extends Notifier<int> {}

should be rewritten to

class CounterNotifier extends Notifier<int> {}

class AnotherNotifier extends Notifier<int> {}

prefer-correct-notifier-file-name​

Suggests ending file names with _notifier.dart for files with Notifiers.

For example,

// LINT: File name of Notifier classes must end with '_notifier.dart'.
//  Try renaming the file.
class SomeNotifier extends Notifier<int> {}

should be rewritten to

class SomeNotifier extends Notifier<int> {}

What’s next​

To learn more about upcoming features, keep an eye on our public roadmap.

And to learn more about our upcoming videos and "Rules of the Week" content, subscribe to our Youtube Channel.

Sharing your feedback​

If there is something you miss from DCM right now, want us to make something better, or have any general feedback — join our Discord server! We’d love to hear from you.

Hello Folks!

If you sat through this session during the Microsoft Azure Infra Summit 2026, you already know that Anand Guruswami and Arun Rabindar from the Cloud Native Experiences team showed us something I have been waiting to see for a while. An AI agent that does not just spit out a Terraform file from a vague prompt, but actually thinks about your workload, talks to you about it, and then hands you something you can put in front of a pull request reviewer without holding your nose.

This is the Azure Deployment Agent, and at the time of broadcast it was still in preview inside Azure Copilot, with the same brains shipping as an open source skill you can plug into GitHub Copilot, Claude Code, Cursor, or whatever your team uses. In this post I want to break down what they showed, why it matters for IT pros, and how you can get hands on with it.

📺 Watch the session: 

Why IT Pros Should Care

Let us be honest about the day to day. Most of the time we are not building a brand new workload from a blank canvas. We are stitching resources together one at a time, copying patterns from a previous project, hunting down the right SKU, checking quotas, then arguing with policy on the way out the door. Different admins do it different ways, and that inconsistency is where risk lives.

Here is what the Deployment Agent changes for us:

• It moves the conversation up a level, from “which resource do I click” to “what am I actually trying to build.”
• It grounds the architecture in the Azure Well-Architected Framework, so the output is not a generic LLM guess, it has reasoning behind it.
• It separates the plan from the code, so you and your team get to review architecture before any Terraform or Bicep gets written.
• It plugs into the tools we already use. Azure portal for the guided path, GitHub Copilot and Claude Code for the power user path.

In short, it's about taking the boring repetitive parts off our plate so we can focus on the parts that need human judgment.

What is the Azure Deployment Agent

The Deployment Agent is a capability inside the Agents (preview) experience in Azure Copilot. Think of it as a virtual cloud solution architect that lives in your Copilot chat. You describe the workload in natural language, and it walks you through a multi step process to land on a production ready deployment.

A few things that stood out from Anand’s portion of the session:

• It supports multi turn conversation. You can clarify scale, security posture, resilience, SKU preferences, region constraints, and the agent will fold those into the plan.
• It produces a human readable infrastructure plan first, complete with trade offs and the reasoning for each resource choice, before it ever writes infrastructure as code.
• Today it generates Terraform inside the portal, with Bicep support landing in the portal experience shortly. In the GitHub Copilot flow you can already pick Bicep or Terraform.
• Once the plan is approved, you get a real artifact. You can open it in VS Code for the Web, or have Copilot open a pull request straight into your GitHub repo.

The deployment itself still goes through Azure Resource Manager. That is important. Your tenant policies, RBAC, naming conventions, and existing guardrails all still apply. The agent is not bypassing your governance, it is generating code that flows through it.

How it Works

Arun did a great job pulling back the curtain on the internals. The agent follows a two step pattern that gives you control at every checkpoint.

• Intent capture. The agent takes your prompt and clarifies the scope, the constraints, and what success looks like. No guessing, no jumping straight to YAML.
• Plan generation. It produces a structured infrastructure plan with inputs, sub goals, a full resource list, configurations, SKUs, and a per resource reasoning section.
• Validation in a loop. The plan runs through evaluators backed by the Well-Architected Framework pillars (reliability, security, cost, operational excellence, performance efficiency). If something fails, the agent regenerates and tries again until the plan is solid.
• Human review. The plan is presented to you in plain language. You can iterate. You can say “prioritize West US 2,” or “swap that SKU,” and the agent will update the plan in place.
• Code generation. Only after you approve the plan does the agent emit Terraform or Bicep. The generated code goes through syntactic validation as well, again in a loop, so it actually parses and is ready to apply.

Under the hood in the GitHub Copilot and Claude Code path, the team has decomposed all of this into an open source skill (the Azure Enterprise Infrastructure Planner) plus the Azure Well-Architected Framework as an MCP tool. The base agent in your editor picks up the skill, runs the phases, calls the MCP tool to ground the output, and then writes the IaC. Same workflow, different host.

When to Use it / Real-World Scenarios

This is not just a toy for greenfield demos. A few places where I see this paying real dividends:

• New workload bootstrapping. A team needs a web app, SQL backend, secrets in Key Vault, monitoring, and a sane region strategy. Instead of three days of clicking and copy pasting, you describe it and review the plan.
• CSV ingestion to SQL automation. The Claude Code demo Arun ran was exactly this. CSV lands, gets processed, rows update in SQL. The agent picked sensible resources, justified each one, and produced Bicep ready to commit.
• Standardizing across teams. Different admins ending up with different shapes for the same workload is the silent killer of operational consistency. A shared agent with a shared planner skill drags everyone toward the same Well-Architected baseline.
• Skill leverage for smaller teams. Not every team has a deep Azure architect on staff. The agent encodes a lot of that experience and surfaces it as conversation.
• Open source customization. Because the skill and MCP tooling are open, platform teams in regulated environments can fork it, add their policy context, their tagging rules, their naming conventions, and ship a tuned version internally.

One honest tradeoff. Right now the agent is greenfield first. The team is actively working on brownfield scenarios, pulling insights from existing workloads and referencing existing resources. If you live entirely in a complex existing estate, expect the experience to keep getting better over the next couple of releases.

Getting Started

If you want to try it this week, here is the short list:

• Ask your Azure tenant administrator to enable Agents (preview) in Azure Copilot. The toggle lives in the Azure Copilot admin center, and without it you will not see agent mode in chat.
• In the Azure portal, open Copilot, expand to full screen, and switch on Agent mode at the bottom of the chat panel.
• Describe a workload in plain language. Be specific about region, scale expectations, and any compliance constraints you care about.
• Review the generated plan before approving. Look at the trade offs section, that is where the agent shows its work.
• For the editor path, install the open source Azure Skills plugin from the microsoft/azure-skills repo, point your IDE at the Azure MCP Server, and run the same workflow inside GitHub Copilot or Claude Code.
• Send feedback. The team is shipping fast and the roadmap (brownfield support, reference workloads, scoped agent permissions, richer architecture diagrams) is shaped by what you tell them.

Resources

• Deployment agent capabilities in Agents (preview) in Azure Copilot: https://learn.microsoft.com/en-us/azure/copilot/deployment-agent 
• microsoft/azure-skills, the open source skill plugin shown in the session: https://github.com/microsoft/azure-skills 
• Azure MCP Server on the GitHub MCP Registry: https://github.com/mcp/com.microsoft/azure 
• Azure MCP Server tools for the Well-Architected Framework: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-well-architected-framework 
• Azure Well-Architected Framework documentation: https://learn.microsoft.com/en-us/azure/well-architected/ 
• Agents (preview) in Azure Copilot overview: https://learn.microsoft.com/en-us/azure/copilot/agents-preview 

Watch the rest of the Summit

If you enjoyed this session, the full Microsoft Azure Infra Summit 2026 playlist is up on YouTube. Sessions on Deployment Stacks, the SRE Agent, Azure Local, AKS networking, and a lot more are all in there. Bookmark this one and share it with your team: https://aka.ms/MAIS/2026-Playlist 

Drop your questions, your war stories, and your wish list for the Deployment Agent in the comments. I read them, the product team reads them, and your scenarios are exactly what shapes the next preview drop. What would you build with it first?

Cheers!

Pierre Roman

Microsoft 365 Copilot is brilliant at working with language. But work isn’t only words, sometimes you don’t want to describe what you need in a back-and-forth chat – you want to see it, touch it, and act on it right where you already are. Picture approving an expense, checking your remaining leave, or booking a desk – without ever leaving the chat to hunt for the right tool. That’s now possible with the UX components in the Copilot canvas using MCP apps model.

Today we’re excited to introduce SharePoint Copilot Apps – a new way to bring rich, interactive UX components directly into the Copilot canvas, powered by the SharePoint Framework (SPFx).

Chat and text are powerful – but not always enough

Think about how often a simple task turns into a longer conversation. You want to get something quickly reviewed. You need the latest tool – but is it on the intranet, or somewhere else entirely? Describing it all in text takes time you don’t have.

Every hop to a different app, portal, or tool breaks your focus and burns minutes that add up across thousands of people. The cost is the constant context-switching tax on your whole organization.

What if the experience you needed was simply there – directly in the flow of your work, inside the Copilot canvas? You ask to see or do something, and the right UX component appears, ready to use.

That’s exactly what SharePoint Copilot Apps deliver: purpose-built UX components that appear in Copilot at the moment they’re useful, so you can review, decide, and act without leaving the conversation.

For developers: just bring your component

Here’s the part developers will love. To create a Copilot UX component, you only have to focus on one thing – building your UX component. Everything else is provided for you by the platform.

And you build it with the JavaScript stack you already know. SPFx supports any JavaScript library or framework you choose – React, Angular, Vue, Svelte, or plain TypeScript. React is the most widely used, so you’ll see it in most of our examples, but it’s never a requirement. That flexibility is a real advantage: your team ships with the tools it’s already productive in, instead of being forced onto someone else’s stack.

That same standards-based foundation unlocks another advantage: your AI coding agents already know how to build this. Because there’s no proprietary platform or bespoke runtime to learn first, tools like GitHub Copilot, Claude, and Codex – or any other coding agent your team prefers – can scaffold, generate, refactor, and debug these components right inside your IDE of choice. The same JavaScript skills that make these easy for humans also make them easy for coding agents, so you get the full productivity boost of AI-assisted development from day one, exactly where you build. In general, coding agents are already excellent at SPFx development – give it a try.

• Web stack development – use the skills and frameworks your team already knows. Any web developer can create these, with whatever JavaScript library or framework they prefer.
• No proprietary development platforms – build on open, familiar web technologies. All based on industry standard patterns.
• Automatic hosting – no figuring out where things get hosted, no external operations and management to stand up. Solutions hosted directly in the customer tenant.
• No infrastructure complexity – nothing to build and run on top of Azure or any externally hosted platform.
• Enterprise-grade security and governance – built on the SharePoint platform, so the security, compliance, and governance your organization already relies on come built in.

This is about extending your existing investments onto the Copilot canvas. The SPFx components and patterns your organization has already built carry forward – now reaching a brand-new surface. And this isn’t a new or unproven foundation: the SPFx ecosystem is already enormous, with tens of millions of end users relying on custom SPFx components every single day.

Better still, the same UX component isn’t tied to one surface. Write it once and expose it across Microsoft 365 – in Copilot, in SharePoint, and in Microsoft Teams – reusing a single component across every channel where your people already work, and maximizing the value of your investment. Don’t reinvent – reuse what you’ve already built, and reach your users everywhere.

Example scenarios

So what can you actually build? Almost anything you’ve previously surfaced in a SharePoint portal or as a Microsoft Teams personal app. Any scenario that was once exposed as a web part or UX element in your portals can now be exposed as a UX component – directly in Copilot, using agents. You can even expose the same component in multiple locations – so your end users can select their preferred experience for accessing the same UX component and capabilities.

Here are three example areas of scenarios to spark some ideas on the art of possible:

Line of Business (LOB) agents

Expose information from your LOB systems right in the Copilot canvas – sales information, business data in charts, cafeteria menus, stock, praise, holidays, time off, help desk, surveys, Customer 360 views, reservations, travel booking, expenses, pay slips, and more.

Corporate Communications and Services agents

Surface your typical intranet scenarios as Copilot UX components – relevant news for the user, the latest information, personal dashboards, organizational information, onboarding tasks, visual Q&A, maps, and more.

Management & Governance agents

Bring administration, operations, and governance tasks into apps – providing UX for typical governance and management operations such as site provisioning, policy enforcement, site dashboards, and more.

Built on industry standards, with enterprise trust

SharePoint Copilot Apps are based on industry standards, implementing the MCP Apps model – so you’re building on an open, interoperable foundation rather than a closed one. It’s the same principle that runs through everything here: open patterns, no lock-in, and components that work across surfaces instead of being trapped on one – and tooling, including AI coding agents, that already speaks your stack.

The key difference from the typical MCP Apps model is that hosting and tool routing are automatic. UX components are automatically hosted in Microsoft 365 tenant, and requests are routed to the right tool for you – there’s nothing to set up, stand up, or wire together. You bring the component; the platform handles the rest.

Why it matters

For the people building and funding these experiences, the value is clear:

• Faster time to value – any web developer can build these with the JavaScript stack they already know, and AI coding agents accelerate the work, so you ship with the team and skills you already have.
• Lower total cost – no new platform to license, no infrastructure to stand up, run, or secure. It’s hosted in your own tenant.
• No license barrier to start – you can begin building these SPFx UX experiences with no specific license requirements. They’re built on declarative agents, which enable baseline agent experiences with simply a Microsoft 365 user license. See agent capabilities and licensing models for the details on the latest licensing requirements.
• Maximized investment – write once, reuse across Copilot, SharePoint, and Teams. Existing SPFx components carry forward instead of being rebuilt.
• Reduced risk – enterprise security, compliance, and governance are built in, not bolted on.

Availability

• Preview: available in early July, alongside the preview of SharePoint Framework (SPFx) v1.24.
• General availability: rolling out later this autumn.

The opportunity ahead

Bringing interactive UX into Copilot opens up an enormous space for innovation – unlocking enterprise experiences across AI-powered work that simply weren’t possible with text alone.

Stay tuned – and try the preview when it lands.

This is just the beginning. We’ll be sharing more demos, videos, guidance, and samples across our open-source and community channels in the weeks ahead.

To stay up to date, join us on our weekly community calls and follow us on LinkedIn and X for the latest Microsoft 365 Platform announcements (including the Copilot area).

We can’t wait to see what you build.

Happy coding! Sharing is Caring! 

The post Going beyond text in Microsoft 365 Copilot – Introducing SharePoint Copilot Apps appeared first on Microsoft 365 Developer Blog.

Olaitan Fashanu: When the New PO Stops Refining—and the Team Starts Self-Destructing

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"If we're actually doing the job of refining this ticket properly, then we will not be creating this tension in the team." - Olaitan Fashanu

The team was working well. They had a strong PO who came to refinement with the problem clearly framed: this is what we want to solve, here's the context, here's the user story, here are the acceptance criteria. The team picked it up, refined it, ran with it. Then change came. A new PO joined—and the routine collapsed. The new PO cared about one thing: hitting the delivery date. Tickets dropped into Jira with no context, no problem statement, no acceptance criteria. Just "this needs to ship by end of month." Within weeks, Olaitan saw the symptoms cascade through the team. Developers asked designers what tickets even meant. QA struggled to maintain quality. Tension built. The diagnosis was clear: refinement had broken. His fix? Bring back the Definition of Ready as a non-negotiable shared standard, and introduce a product trio—business viability, technical feasibility, and design usability collaborating on every story before it reaches the rest of the team.

In this segment, we talk about the Definition of Ready and the product trio collaboration model.

Self-reflection Question: What's the symptom you're seeing in your team right now—and could the real source be how stories are getting refined, not how they're getting built?

Featured Book of the Week: The Secrets of Facilitation by Michael Wilkinson

Olaitan calls out The Secrets of Facilitation by Michael Wilkinson as the book that shaped how he handles difficult moments. The book teaches the power of asking the right question at the right time—clarifying questions, probing questions, the questions that drive a stuck group forward. "You will understand how, when to ask clarifying questions, ask really powerful questions that will help you drive or probably help you reach your goal in any session you find yourself." For Olaitan, the biggest payoff was learning to manage group dynamics in real time—what to do when something said in a meeting lands badly, when a comment threatens to derail the room. As a Scrum Master, you live in those moments. This book hands you a toolkit for them.

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Olaitan Fashanu

Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision.

You can link with Olaitan Fashanu on LinkedIn.