Source: qdash /integrations - c61 capability-first refinement, 2026-08-13
v5 made the next step clear, but concealed too much of the opportunity. This pass keeps the setup path simple while giving operators a calm overview of what they can add and why it might matter.
Show the possibility, then reveal the detail
The page should not make operators invent a job before they can understand the product. Four broad capability groups are enough to explain the landscape, with one sentence that connects each group to an operator benefit.
Capability overview
Existing connections remain visible first. Available integrations follow as four quiet rows that communicate type, value, and representative destinations at a glance.
One level of integration detail
Selecting a capability group reveals a short comparison. This is where individual vendors appear, each with a specific reason to choose it and one setup action.
Calibrate the job language
Keep the operator value, but move it into supporting copy. Category labels should describe what can be added; the sentence beneath explains why someone would add it.
| Too specific as navigation | Capability label | Why it matters |
|---|---|---|
| Get findings into the SOC | Security & observability | Investigate qdash activity alongside existing security data. |
| Wake responders | Team notifications | Send selected findings where people already coordinate and respond. |
| Move findings to remediation | Remediation tracking | Turn findings into owned, trackable work. |
| Hand evidence to auditors | Evidence storage | Keep evidence available for retention, review, and audit. |
The middle ground
Show enough of the catalog for an operator to understand the product: four capability groups, recognizable destinations, and a clear benefit for each. Keep configuration out of the way until a vendor is selected. The page explains the possibility space without presenting eight uncreated integrations as if they were already part of the operator's system.