JSM embeddable widget (virtual service agent): every bot reply renders as "Unsupported doc"

Question

Site: mydigitaloffice.atlassian.net

Project: TPS (service desk ID 3115)

Channel: Embeddable widget, widget type, widget version 2026-09-28_12-27

Every message returned by the virtual service agent in the embeddable widget renders as a card reading "Unsupported doc" instead of the answer text. This affects all bot replies—knowledge-base answers, fallback messages ("Hmm, I'm still having trouble understanding"), and email-capture prompts alike.

The same agent answering the same questions on the customer portal renders perfectly.

Critically, this reproduces inside Atlassian's own admin UI, with no customer code on the page:

Project settings → Channels → Widget → the live preview panel. That rules out our embed script, our page, and our CSP.

Steps to reproduce

* Open Project settings → Channels → Widget for a JSM project with the virtual service agent enabled.
* In the built-in preview, send any message (e.g., "What are all the plans in TruePlan?").
* The agent responds—Yes/No feedback buttons appear, so generation succeeded—but every message block renders as a card reading "Unsupported doc."

Expected vs. actual

* Expected: the agent's reply text renders in the widget, as it does on the portal.
* Actual: one "Unsupported doc" card per message block. No answer text is visible to the end user.

Our analysis (payload + bundle inspection)

We captured the widget's network traffic and read the published widget bundle. The server response is correct—the failure is client-side, in the widget's rendering path.

1. The server sends valid ADF. Response from authorType: "bot", contentType: "ADF":

{"type":"doc","version":1,"content":[
  {"type":"paragraph","content":[
    {"type":"text","text":"No problem. Please enter your email address…"}]}]}

That is a well-formed, single-level ADF document and renders fine on its own.

2. The widget then re-wraps it before rendering. In https://jsd-widget.atlassian.com/assets/iframe.js, the bot-message conversion path takes the already-complete ADF document and passes it through a paragraph builder and then a doc builder:

* The paragraph builder converts strings into text nodes and passes objects through unchanged
* The doc builder wraps whatever it receives in {type:"doc", version:1, content:[…]}

Given an ADF object (not a string), the result is a document node sitting in an inline position. That is an invalid ADF, so the Atlaskit renderer falls back to unsupportedInline, whose label is built as "Unsupported " + node.attrs.originalValue.type → "Unsupported doc."

In other words, the conversion looks like it expects a plain string from the server, but the server is sending an ADF object (contentType: "ADF"). Our read is a contract mismatch between the conversation history API and the widget's bot-message renderer.

3. Two observations that corroborate this:

* Reporter (end-user) messages render fine in the same widget—they take a different branch in the same message router, so they never hit this wrapper.
* The portal works because it is a separate application that does not use this widget bundle.

(Module/symbol names are minified and change per build, so we've described the code functionally. We can supply the exact extracted functions, the full HAR capture, and screenshots on request.

Impact

Customer-facing. The virtual service agent has been effectively unusable in our embedded widget, and end users see "Unsupported doc" where an answer should be. No configuration change resolves it—see below.

What we have already ruled out

* Our integration: embed script unchanged for 10 months and identical to Atlassian's documented snippet; reproduces in Atlassian's own preview with none of our code present.
* Knowledge base content/linking: the linked Confluence space (TKB1) has 50+ published articles and is correctly linked to TPS. The fallback message—which comes from no article at all—renders as "Unsupported doc" too.
* KB permissions / article formatting: tested across visibility settings and article styles; no effect. The failure is structural, before any content-specific handling.
* CSP / iframe / hosting: the widget loads and functions; only the message body fails to render.

What we're asking

* Is this a known defect? If so, please share the public issue key so we can watch it and any ETA.
* Is there a supported workaround—a widget configuration, a version pin, or a flag—that restores correct rendering in the meantime?
* Separately: Can you confirm whether custom Rovo (Studio) agents are supported in the embeddable widget or are planned to be? Our widget currently surfaces the generic virtual service agent rather than our custom agent, and we've found no supported way to attach a Studio agent to this channel.

Josh · Answer

“Unsupported doc” on every Virtual Service Agent reply in the embeddable widget (including fallback text) usually means the widget front-end failed to render the ADF/document payload the bot returned — not that the agent has no answer.

Checks that narrow it:

* Confirm the same agent answers correctly in the portal / other channels. If portal is fine and only the embeddable widget shows “Unsupported doc”, it’s a widget renderer / version mismatch (you noted widget version 2026-09-28_12-27).
* Try a fresh embed snippet from Project settings → Channels → Embeddable widget (regenerate the script) and hard-refresh the host page; stale embeds after Atlassian chat/widget updates are a common cause.
* Disable custom CSS/JS on the host page that might strip or rewrite the widget iframe/shadow DOM.
* If KB answers and fallbacks both fail identically, open Support with site mydigitaloffice.atlassian.net, project TPS / desk 3115, widget version, and a HAR or screenshot — this pattern has been a product bug on specific widget builds rather than a misconfigured intent.

As a temporary customer-facing workaround, point users at the portal link until the widget build is fixed/regenerated.

Sami Shaik · Answer

@Yagnik Satani , that is a complete defect report, and reproducing it in Atlassian's own preview panel is what makes it one; there is nothing left for you to rule out. Straight answers to your three questions as of today:

1. Known defect? I cannot find a public ticket for it on jira.atlassian.com, so treat it as unreported until Atlassian says otherwise. File it through Support with exactly what you wrote here (the captured response showing contentType: "ADF" with a valid single-level document, and the bundle's double-wrap before render), and ask them to create a public JSDCLOUD issue so others can vote and watch. The widget version string in your post (2026-09-28_12-27) is worth quoting in the ticket: a widget build dated three days before your report, with the same agent fine on the portal, reads as a regression in that build rather than anything on your side.

2. Workaround or version pin. There is no pin: the widget bundle is served by Atlassian from the embed script, so every customer gets the current build. The one interim control you have is in Space settings → Channels & self service → Widget: switch from Virtual service agent to Basic widget (use the virtual service agent in your widget). Customers lose deflection in the widget but can still raise requests, and the agent keeps working on the portal and in your other channels until the build is fixed. Flip it back once Support confirms the fix.

3. Custom Rovo Studio agents in the widget channel. Not documented as supported. The widget channel documentation covers the virtual service agent only (intent flows and AI answers), and the Rovo agent documentation states that custom agents are available on the portal for Atlassian accounts (set up your virtual service agent). So the widget can carry the stock agent today, and a Studio-built agent is a portal and help-center feature; raise that as a separate feature request rather than folding it into the bug.

If the Support ticket produces a public issue key, post it back here; this thread will be the first search hit for the next person who sees "Unsupported doc."