Copilot UX Components: Microsoft Named Them. Here Is What You Can Actually Build.

What Microsoft just confirmed

On 23 September 2026 Microsoft shipped SharePoint Framework 1.24 beta 5 and settled the name. The interactive experiences that render inside Microsoft 365 Copilot are Copilot UX components. That is the final name. The July working title was SharePoint Copilot Apps. Through August the roadmap called them Copilot Components. The 1.24 preview release notes now close the debate.

The product idea did not change with the name. Copilot can stop answering with a paragraph and instead open a real interface: a chart, a map, a KPI strip, a form, an approval. The user stays in the conversation. The component is hosted in the Microsoft 365 tenant. Sign-in is the signed-in user’s identity. Permissions are the user’s permissions. You build the experience. You do not stand up a host, a routing layer, or a separate auth dance for the MCP Apps model underneath.

How we got here

• 8 July 2026 — beta 1. SharePoint Copilot Apps enter public preview with SPFx 1.24. Microsoft’s pitch: move from intent to action inside the Copilot canvas. Expense approval, incident triage, and onboarding checklists are the examples they lead with.
• 27 August 2026 — beta 3. The roadmap post treats Copilot Components as the likely name. Display mode becomes predictable. Component updates stop colliding on Teams manifest versions. Declarative agent manifests are validated at build time. New scaffolds target agent manifest v1.8.
• 17 September 2026 — beta 4. A new tool-resolution approach ships. It does not hold.
• 23 September 2026 — beta 5. Microsoft rolls tool resolution back to the beta 3 model, locks the name as Copilot UX components, and says the next step is most likely a release candidate on the way to October GA. React 18 remains in the 1.24 preview line.

That rollback matters more than the naming. If your lab project was built against beta 4’s tool resolution, treat beta 5 as a reset to the beta 3 contract, not as a quiet patch. Rebuild, retest in the Copilot Workbench, and only then redeploy.

What a Copilot UX component actually is

A Copilot UX component is a client-side SPFx component that extends BaseCopilotComponent (from @microsoft/sp-copilot-component), not BaseClientSideWebPart. It is packaged with a declarative agent in one .sppkg. The agent is what makes the component discoverable in a conversation. The component is what the user sees and clicks.

Three files do most of the work:

1. The component class and its manifest. The manifest declares the component id, supported display modes, and the tools the agent can call. Each tool has a properties schema describing the arguments Copilot may pass in.
2. The declarative agent under copilot/ — name, instructions, conversation starters, and the action that maps to a tool.
3. config/copilot-agent.json, which groups one or more components into that agent by component id.

Microsoft implements this on the MCP Apps model, then hides the hosting. You define when the component should activate. The tenant hosts it and routes the tool call. That is the difference from a hand-rolled declarative agent plus a custom web host: there is no server for you to operate just to put a card in the chat.

Share the interface, the business rules, and the styling in a UI layer the host does not own. Keep the SPFx class thin: read host context (theme, display mode, tool arguments), render into this.context.domElement, and call the bridge when the user wants fullscreen or needs to hand a result back to the conversation.

What beta 3 still gives you, and what beta 5 changed

Beta 5’s own note is short: tool resolution returns to the beta 3 approach because the beta 4 model mis-resolved tools. Everything else you should design against is the beta 3 hardening, which beta 5 keeps:

• Default display mode sticks. A newly invoked component opens in the mode declared in its manifest. Closing it returns the thread to the inline view and does not immediately reopen the component. An explicit user request can open fullscreen again. Earlier previews snapped the component back to its default size at the wrong moment.
• Version bumps on content change. If you ship an update and forget to bump the Teams manifest version, the build now increments the hotfix segment for you. That removes a class of “same version” conflicts in the app catalog. Clearer admin-center errors are still follow-up work.
• Agent manifest checks at build time. A declarative agent that does not match the schema fails while you build, not after you have deployed and wondered why the tool never appears in Copilot.
• New projects start on agent manifest v1.8. Existing solutions are not rewritten for you. Bump the manifest version in the project when you are ready to take the newer contract.
• React 18. This has been the longest-running SPFx request. The 1.24 preview is the place to find libraries that break under React 18’s rendering rules before GA, not after.

What becomes possible

Text answers are fine for “what is our leave policy?” They are a poor interface for “approve these three expenses” or “show me open deviations by site.” Copilot UX components exist for the second kind of job: the answer is an object the user can act on.

Inside the thread, not beside it

Inline is mandatory. The card appears in the flow of the answer, before or as part of the model’s response, using Fluent 2 spacing, type, and tokens so it feels like Copilot rather than an iframe from another product. Side-by-side or fullscreen is for work that needs a table, a map, or a multi-step form. Microsoft’s UX guidance for MCP apps in Copilot is explicit: every experience must work inline; richer layouts are optional.

Actions with the user’s rights

Because the component runs as the signed-in user, a button that writes to a SharePoint list, calls Microsoft Graph, or starts a Power Automate flow inherits that user’s permissions. That is also the governance constraint. Do not design a component that needs broader rights than the person in the chat. If a finance controller should approve and an employee should only view, that split belongs in the data and the flow, not in a hidden service account.

One UX, two hosts — later

The architecture is set up so the same React tree could render in Copilot and, eventually, on other Microsoft 365 surfaces. Today the preview renders in the Copilot experience only. Build the shared UI now if you want that option. Do not promise a SharePoint page placement in a current project plan.

Use cases worth building before October

Pick one workflow where the user already asks Copilot a question and then leaves to finish the job in another tab. That gap is the component.

• Expense and purchase approval. The agent summarises the request. The component shows amount, vendor, policy flag, and Approve / Send back. The click writes the decision and the audit fields. This is the pattern Microsoft has used since the July announcement, and it matches how we already model multi-stage approvals in Power Automate.
• Incident and deviation triage. A quality or IT lead asks what is overdue. The component lists open items with owner, age, and severity, and lets them assign or escalate without opening the QMS and the intranet separately.
• SOP acknowledgement. “What do I still need to sign?” returns the three documents, the version, and an Acknowledge action that stamps the person and the time. That is the same obligation we surface on regulated intranet home pages — moved to the place the employee already asks questions.
• Personal approval queue. Power Automate already knows what is waiting. The component is the inbox: one card per item, act, then the next.
• KPI strip for a leader. “How is GxP training this week?” should be three numbers and a trend, not a paragraph that quotes a dashboard. Charts and KPI layouts are called out in the release notes for exactly this.
• Site or route map. Field operations, campus services, and multi-site pharma all ask “where.” A map component beats a list of buildings pasted into chat.
• Onboarding checklist. A new hire asks what is left in week one. The component shows tasks, owners, and completion, and writes status back to the list the HR intranet already uses.
• Structured data capture. A short form inside the chat — travel request, facility ticket, stock adjustment — with validation, instead of hoping the model extracted every field from a sentence.

Skip components whose only job is to restate a document Copilot already summarises well. If there is no click that changes a system of record, you built a decorated answer.

How development works

Install the preview generator with the @next tag. The current generator on the default npm tag does not offer this project type.

npm install @microsoft/generator-sharepoint@next --global
yo @microsoft/sharepoint

Scaffold a Copilot UX component and pick a template: Minimal, No framework, or React. For anything with a real interface, use React. The template is already on React 18 and Fluent UI v9. You will also need the Heft-based toolchain this preview uses — follow the current “set up your SPFx development environment” page rather than an older Gulp guide.

Then work in this order:

1. Name the tool around the job, not around the screen. “Show pending SOP acknowledgements” is a tool. “Render card” is not.
2. Define the properties schema for the arguments the model must supply: user, site, date range, record id. Invalid shapes should fail in the schema, not as a blank card.
3. Keep render() boring. Read display mode, theme, and tool output. Mount the React tree. Expose requestDisplayModeAsync('fullscreen') only when the inline card is genuinely too small.
4. Point the declarative agent at that tool in declarativeAgent.json, with instructions that tell the model when to call it and when to stay in text. Conversation starters are how you demo it to sponsors.
5. Register the component id in config/copilot-agent.json. If the GUID in the manifest and the agent config drift, the tool never appears.
6. Test in the Copilot Workbench before you touch a tenant. This is the local loop for the preview.
7. Package and deploy to the tenant app catalog. The add-and-enable flow for the app is required for the agent to be usable. During preview, components are not distributed through the public store.
8. Exercise the real permission boundary with two accounts: one who should act, one who should be refused by SharePoint or Graph, not by a cosmetic hide of the button.

export default class ApprovalsCopilotComponent extends BaseCopilotComponent {
  public render(): void {
    const props = {
      mode: this.context.displayMode,
      theme: this.context.theme,
      items: this.properties?.items ?? [],
      onOpen: () => this.context.requestDisplayModeAsync('fullscreen'),
      onDecide: (id, decision) => this.completeDecision(id, decision)
    };
    const root = createRoot(this.context.domElement);
    root.render(<ApprovalsCard {...props} />);
  }
}

Treat that as the seam, not as an API guarantee. Preview method names and context fields can still move before the release candidate. The samples gallery Microsoft links from the release notes, and the Copilot Developer Camp labs, are the place to copy a current scaffold.

Limits you should say out loud in a proposal

• Copilot canvas only in this preview. Other surfaces are “in the works,” which is not a date.
• No store distribution yet. Tenant deployment only.
• Licensing for GA is undecided. Preview does not require a Microsoft 365 Copilot license and has been described without consumption charges. That can change in October. Price the build; do not price the run-rate until Microsoft publishes the GA terms.
• Beta 4 tool resolution is withdrawn. Standardise the team on beta 5 / the beta 3 resolution model.
• npm audit findings on the generator are acknowledged by Microsoft. Their current assessment is that those findings do not affect SPFx runtime or dev-time security. Still review them with your security team before a governed tenant adopts the preview toolchain.
• APIs will move until GA. Pin the generator version in the repo and budget a regression pass when the release candidate lands.

How we would take this into a client tenant

We would not start by scaffolding a hello-world card. We would start from a workflow we already run on SharePoint and Power Automate — an approval, an acknowledgement, a queue — and ask whether the Copilot thread is a better front door than the intranet web part. If yes, the component is a new host for UI we already trust. If the data model, the audit log, or the permission story is fuzzy, the component will only make that fuzziness faster.

A sensible pre-GA plan is a two-week lab: one agent, one tool, one component, Workbench first, then a non-production tenant, with a written note on what breaks when the RC arrives. Production cutover waits for the October general availability and for the licensing note Microsoft still owes.

Questions we are already getting

Related reading