"It's a Forge app, so all the data stays inside Atlassian."
You'll hear this from every survey tool vendor on the Atlassian Marketplace. It's technically true. It's also not the whole story. Understanding the difference between hosted on Atlassian infrastructure and written to Jira fields is probably the most important distinction you can make when evaluating survey tools for JSM.
What Forge Actually Means
Forge is Atlassian's app runtime. Apps built on Forge execute on Atlassian's infrastructure and cannot exfiltrate data to third-party servers. This addresses two real concerns:
Data residency. If your organisation is in an Atlassian data residency region, Forge apps stay within that boundary. Data doesn't leave your Atlassian tenancy and route through a vendor's own infrastructure.
Security posture. Traditional "Connect" apps (the older Atlassian app type) ran on vendor-operated servers. Forge eliminates that external dependency. There's no vendor server to be breached, no OAuth token exchange with a third party.
These are meaningful distinctions, especially for security-conscious procurement. If your organisation has data handling requirements or is evaluating Forge apps for the first time, the Forge label is a genuine signal — not marketing fluff.
But it's not the whole picture.
The Part the Vendor Might Not Mention
Forge apps can store their own data in what Atlassian calls the Forge storage layer — a key-value and document store tied to the app installation. Data in Forge storage lives inside Atlassian's infrastructure. It is not accessible from outside Atlassian.
Here's the problem: it's also not accessible from the rest of Jira.
If a survey app writes your CSAT responses to Forge storage, those responses are only visible through that app's own interface. You cannot:
- Filter Jira issues by CSAT score using JQL
- Build a Jira dashboard gadget that shows average satisfaction over time
- Trigger a Jira Automation rule based on a low score
- Include CSAT in a Jira custom report or sprint health board
Imagine filtering all tickets with a CSAT score below 3 in the last 30 days to identify recurring patterns. That query only works if the score exists as a Jira field on the originating issue. If it lives in the app's storage layer instead, the data is isolated — safe, yes, but functionally siloed.
Field Writeback: The Distinction That Matters
Some Forge apps write survey responses back to Jira custom fields on the issue that triggered the survey. When this happens, the score becomes a first-class Jira data element: it's on the issue, it's indexed, and it behaves exactly like any other field.
With field writeback in place:
JQL works. You can run queries like:
project = IT AND "CSAT Score" < 3 AND resolved >= -30d ORDER BY "CSAT Score" ASC
Jira dashboards work. The built-in average value gadget, filter results gadget, and pie chart gadget all work against Jira fields natively.
Jira Automation works. A rule triggered by "field value changed → CSAT Score → is less than 3" can automatically create a follow-up task, assign it to a team lead, or send a notification. None of this requires any external integration.
Reporting tools work. If your team uses Advanced Roadmaps, Jira's built-in reporting, or an external BI tool pointed at Jira's API, field-level CSAT data is available. App-layer data is not.
The Question to Ask Every Vendor
Before buying any JSM survey tool, ask exactly this:
"Do survey responses write back to custom fields on the originating Jira issue, and are those fields queryable via JQL?"
A confident yes with a demonstration is the answer you're looking for. "The data is in Atlassian" without a specific answer about Jira fields is not.
Follow-up: "Can I build a Jira dashboard gadget using the response data without logging into your app?" If the answer is no, the data is in Forge storage, not in Jira.
What Native JSM Surveys Do and Don't Do
Atlassian shipped native survey functionality in early 2026, and it's worth understanding where it sits on this spectrum.
Native JSM surveys are useful for basic use cases: a single CSAT question, thumbs up/down or star rating, and a comment field. Setup is straightforward, and there's no app to install.
The limitations are real, though. Scale types and question wording are limited — you can't run a proper NPS (0–10 net score) or CES (7-point effort scale) natively. Reporting depth is basic; you see aggregate counts but can't filter by agent, ticket type, or custom criteria without exporting data. And the interaction between native survey responses and JQL is minimal compared to what field-writeback apps can do.
Native surveys are a reasonable starting point for teams that want "something" without procurement friction. They're not a long-term solution for a team that takes satisfaction data seriously.
What Good Looks Like
A Jira-native survey setup means:
- Survey triggers on ticket resolution (or a custom automation event)
- Response is captured inline in the JSM portal or via a channel the customer actually uses
- Score and comment write back to a custom field on the Jira issue
- Score is immediately queryable in JQL, visible in Jira dashboards, and available as a trigger for Jira Automation rules
- No data leaves Atlassian at any point
Myra is a Forge app that writes CSAT, NPS, and CES responses back as Jira custom fields — so reporting, JQL filtering, and Jira automations all work natively without any external tool or manual export.
The Evaluation Shortcut
If you're evaluating tools quickly, ask for a live demo of this specific workflow:
- Resolve a test ticket with an assigned survey
- Submit a low test rating
- Open Jira's issue navigator and run a JQL query filtering by that score
- Show a Jira dashboard gadget displaying average score for the last 30 days
If the vendor can walk through all four steps without opening their own admin dashboard, the data is in Jira. If steps 3 or 4 require switching to the app's reporting interface, you're looking at a Forge-hosted but Jira-siloed tool.
The infrastructure question matters. The field question matters more.