Yes, that's exactly the outcome we experienced. The disconnected data model forces a manual reconciliation process that becomes the core of your reporting workflow, not a one-off task.
To answer your question, you don't build dashboards from the survey data directly. You're forced to create a separate "master" tracking record, typically a custom table for your control assessments. The survey responses then become just one piece of evidence you have to manually link or periodically import via scripts. Your dashboard sources data from the tracking table, leaving the actual survey tool as a disconnected front-end.
This creates the multi-place login problem you guessed. Analysts live in the survey interface to send reminders, but management and compliance live in the custom dashboards. The moment someone needs to verify a specific answer, you're jumping between systems. The audit trail breaks across that gap.
Support is a product, not a department.
You're only discovering this now? The rigid data model has been the foundation of every ServiceNow survey use case failure story I've ever been roped into. Your point about convoluted joins is the giveaway - if you need a database diagram just to pull a simple trend report, the tool has already failed.
It's not just that the conditional logic is limited, it's that it's a trap. You build a basic branching path, it looks like it works in a demo, and then you get your first audit request for a full evidence chain. You suddenly realize the "logic" doesn't actually create a relational structure, it just hides questions. The audit trail is broken from the start, and you're left defending a design you didn't build.
The real question is whether the platform's marketing matched the reality presented to you. I've seen three separate teams sold on using the OOB survey tool for compliance, only to find themselves building a parallel tracking system within six months.
cg
That rigid data model is such a killer for any kind of trend analysis. I tried using it for basic compliance attestations and hit the same wall - you can't just ask "how did this answer change from last quarter?" without building a whole custom reporting engine.
Your point about the lack of true conditional logic is spot on. It totally fails for anything resembling a real control workflow, where an answer of "No" should trigger a whole new set of fields for remediation plans and evidence uploads. It just wasn't built for that.
measure twice, ship once
The orphaned evidence piece is exactly what worries me. If a "no" triggers a plan field but the attachment isn't tied to it, how do you even prove the evidence belongs to that specific failure later? It sounds like you're just creating more manual reconciliation work.
You mentioned the performance hit with each survey cycle. Did the slowdown start becoming noticeable with a certain number of responses, or was it more about the volume of controls being assessed?
You've hit on a real-world headache. It's absolutely a manual reconciliation process, and you're right to be worried. In an audit, you'd be scrambling to match that orphaned evidence file to the specific "no" response from three months ago, probably by timestamps or naming conventions you have to hope people followed.
To your second question, the slowdown seemed more directly tied to the volume of controls being assessed. Each new control in a cycle meant another layer of those convoluted sys_id relationships being processed. It wasn't about having 500 responses to one control, it was about trying to run 50 different controls through the same survey instance. The joins just couldn't handle it gracefully.
Keep it constructive.