PowerLeap Logo

Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

Chat shows raw JSON instead of an answer

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
Confirmed officialConfirmed by Microsoft documentation or an official statement.
Severity
Degrading
Typical time lost
Hours

Identification

Topics & variablesAll channels

Verification & changes

  1. Verified

    Doc check by human: Official HTTP-node and list-of-results docs plus practitioner tutorial re-read during seed migration; parse requirement still documented.

  2. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

  3. Change

    Initial record created from the seed dossier (migration wave 1).

Related

Are you in the right place?

  • Your agent calls a tool, a connector, an HTTP request, or a flow.
  • The chat shows the result as raw JSON, with braces, quotes, and field names.
  • The data inside the JSON is correct — it is only unreadable.
  • Or: the parsing worked before and now fails, although you changed nothing.

If users see {"explanation_of_tool_call": …} only in production → see Raw explanation_of_tool_call JSON visible. That JSON is orchestrator metadata, not a tool result. If a prompt fails with "A JSON could not be generated. Edit your prompt instruction…" → see "A JSON could not be generated". If the flow's output never arrives at all → see "No output was received from flow".

What's happening

Cause 1: The result was never parsed. Tools, connectors, HTTP requests, and flows return results as plain text. Copilot Studio does not turn that text into fields on its own. When a message node shows the raw variable, users see the JSON as-is. Think of a letter that arrives still inside its envelope: the content is there, but nobody opened it. A Parse value node opens the envelope and turns the text into named fields.

Cause 2: Parsing broke after an upstream API change. The node's schema comes from one pasted sample. That sample schema is frozen; it never updates itself. When the API behind the tool changes its structure, the parsing breaks silently. You changed nothing — and the chat falls back to raw or broken output.

For technicians

The HTTP request node's error response variable is typed Any and needs Parse value before use. Flow outputs arrive as strings; using them as question options requires parsing the JSON into a table first. Even Microsoft's own list-of-results tutorial inserts a Parse JSON step with a manually pasted schema. The sample-derived schema freezes one structural snapshot of the upstream API. There is no schema-drift alarm; an upstream change surfaces only as broken output in the chat.

How to fix it

Solution 1

Official workaround

Add a Parse value node right after the action

  1. Run the tool or action once and copy the raw JSON from the chat.
  2. Open the topic that calls the action.
  3. Select "+" directly after the action node.
  4. Select "Variable management" → "Parse value".
  5. In the node, pick the action's output variable as the value to parse.
  6. Set the data type to "From sample data".
  7. Select "Get schema from sample JSON" and paste the copied sample.
  8. Save the parsed result into a new variable.
  9. Point your message node at the parsed fields, not at the raw variable.

✅ You should now see: readable fields in the chat instead of raw JSON.

Solution 2

Community workaround

Re-pull the sample schema after an upstream change

Use this when the parsing worked before and broke without any change on your side.

  1. Call the API or flow once, outside the agent, and copy a fresh response sample.
  2. Open the existing "Parse value" node.
  3. Select "Get schema from sample JSON" again.
  4. Paste the fresh sample and confirm the derived schema.
  5. Check every later node that reads the parsed fields; renamed fields need re-mapping.

✅ You should now see: parsed fields filled with current data again.

Check that it worked

Trigger the tool once in the test pane and once in your published channel. Expected: the answer shows readable text, with no braces, brackets, or field names.

If it didn't work

  • The upstream API changed. This is the most common relapse. The frozen sample schema no longer matches reality. Re-pull the schema from a fresh sample, as in the second solution.
  • You parsed the wrong variable. Check that the Parse value node reads the action's output, not another variable.
  • The sample was incomplete. A sample missing optional fields derives a schema without them. Capture a sample from a response that contains every field you need.
  • The channel still runs your old agent version. Publish and propagation delay is suspect number one. See Teams answers with an old version of your agent.

Prevent it next time

  • Follow Parse value discipline: a Parse value node after every tool, connector, or HTTP action.
  • Treat every upstream API change as a schema review trigger; re-pull the sample before users see broken output.
  • Note next to the topic which API version each sample came from.

Evidence

  • Official documentationlearn.microsoft.com

    The HTTP request node's error response variable is typed Any and must be converted with a Parse value node before it can be used.

  • Official documentationlearn.microsoft.com

    Even Microsoft's own list-of-results tutorial requires a Parse JSON step with a manually pasted schema before flow data becomes usable.

  • MVP blogippu-biz.com

    A connector returns correct data, but the chat shows raw JSON until a Parse value node with a sample-derived schema is added after the action.