Why do Microsoft 365 Copilot API plugins return unusable text responses?
When you connect an internal system to Microsoft 365 Copilot via an API plugin, Copilot retrieves the correct data and then summarises it as plain text. The data is accurate. The format is nearly impossible to act on. A busy operations manager does not want to read a paragraph describing order status, carrier details, and tracking references when they need a status badge and a single button to track the shipment.
This gap between Copilot having the right answer and presenting it in a way people can act on is the core problem. For wholesale distributors, manufacturers, and professional services firms building real Copilot extensions, closing this gap is the difference between staff adoption and staff quietly returning to their old systems.
What are Adaptive Card responses and how do they work inside Microsoft 365 Copilot?
Adaptive Card responses replace Copilot's default plain-text narration with a structured visual card rendered directly inside the chat. When your API plugin runs, Copilot merges the JSON response data into a card template you define. The template specifies headings, fields, status indicators, images, and action buttons. The result is a clean, formatted card rather than a paragraph of interpreted text.
The technical setup is straightforward. In your plugin manifest, each function points to a response rendering template. The template uses binding expressions such as ${status} or ${order.deliveryDate} to pull values directly from your API response. If your team has already built cards for Microsoft Teams bots, most of that work carries over directly into Copilot plugins.
Plugin manifest configuration: Each API function in your OpenAPI spec can reference a dedicated card template, so different query types render different card layouts automatically.
Data binding expressions: Values from your API JSON response bind directly into the card using simple placeholder syntax, with no model interpretation in between.
Conditional field display: Use $when expressions to hide empty fields, so cards never display blank labels when optional data is missing from the API response.
Adaptive Card Designer: Preview and validate card layouts in the Adaptive Card Designer before deployment. Always test in the live Copilot surface, not just the designer, because some elements render differently inside chat.
Why do structured card responses increase Copilot adoption in operations teams?
Accuracy is the first reason. When Copilot narrates raw JSON into prose, it interprets values. A status field labelled PARTIAL may be described as 'partially complete' in one response and 'incomplete' in another. Adaptive Cards display the exact field value from the API, styled and unambiguous. For account balances, compliance statuses, stock levels, or order states, that determinism is critical.
Action capability is the second reason. A text paragraph cannot do anything. A card can carry an Action.OpenUrl button that deep links directly into your ERP, WMS, or CRM, or an Action.Submit button that posts back to your API. A manager reviewing a leave request can approve it from inside the card without leaving the Copilot chat. This is where Copilot stops being a search interface and starts being a place where operational work actually happens.
Kernel Flow deployed this approach for a logistics client whose dispatch team was querying consignment status dozens of times per day. Replacing text responses with a structured card showing a colour-coded status, three key data fields, and a direct tracking button cut the time to find and act on information significantly. Adoption increased because the tool felt purpose-built rather than bolted on.
What are the practical limitations when building Adaptive Card responses for Copilot?
Cards inside Microsoft 365 Copilot are more constrained than cards inside Microsoft Teams. Not every Adaptive Card element renders identically, and some has available in Teams bots are stripped or behave differently in the Copilot chat surface. Testing exclusively in the Adaptive Card Designer is not sufficient. Always validate in the live Copilot environment before treating a card as production-ready.
Fallback behaviour is handled sensibly. If a card fails to render, Copilot reverts to a text response rather than breaking the query entirely. This protects staff from a styling error causing a complete failure, but it also means broken cards can go undetected if teams do not check the rendered output directly.
Copilot surface constraints: Some Adaptive Card elements that display correctly in Teams bots are stripped or altered inside the Copilot chat interface, so test every card in the actual deployment surface.
Silent fallback risk: When a card cannot render, Copilot silently falls back to plain text, which means card errors may go unnoticed without active output monitoring.
Template maintenance: Card templates are separate JSON files that must be updated whenever your API response schema changes, adding a maintenance dependency to your plugin lifecycle.
Action button limitations: Action.Submit buttons that post back to an API require careful authentication and endpoint configuration, particularly when connecting to on-premises systems or legacy ERPs like SAP or MYOB.
Which business types benefit most from Copilot API plugins with card responses?
Wholesale distributors and manufacturers with high-frequency operational queries, such as order status, stock levels, or shipment tracking, see the clearest gains. Staff running dozens of lookups per day get structured answers with direct action buttons instead of copying information between systems.
Professional services firms using Microsoft 365 and tools like Salesforce, Dynamics 365, or SharePoint benefit from cards that surface case status, document approvals, or client data directly inside Teams and Copilot without requiring system switches. Insurance and compliance-heavy businesses gain from the deterministic data display, where exact field values matter and model interpretation of statuses is not acceptable.
Wholesale and distribution: Order status, consignment tracking, and inventory lookup cards with direct action links into WMS or ERP systems reduce query time and eliminate manual system switching.
Manufacturing operations: Production run status, quality check outcomes, and supplier order confirmations rendered as cards give floor and operations managers instant visibility without leaving Microsoft Teams.
Professional services: Client file status, approval workflows, and billing milestone cards integrated with Salesforce or Dynamics 365 let client-facing staff act on information without leaving the Copilot interface.
Insurance and compliance: Policy status, compliance flags, and claims progress displayed as deterministic cards eliminate the interpretation risk of plain-text summaries where exact values are legally significant.