Source: qdash /integrations — c61 JTBD-first refinements, 2026-08-13
This pass starts from operator jobs instead of connector inventory. The framing change is simple: integrations are not the object of the page; operating outcomes are. Connectors appear only as routes that complete a job, so projected integrations stop feeling like uncreated clutter and start reading as measured paths a job could take.
From "connectors" to "jobs"
The directory-first page asks the operator to parse the roadmap. The job-first page asks what they are trying to accomplish, then reveals the minimum integration surface needed to accomplish it.
Job cards first
Replace the connector grid with a short set of operating jobs. Each card carries the current truth state, the local proof qdash already has, and only the integrations relevant to that job.
Prove nothing leaves
liveSecurity wants confidence that qdash is observing locally before any external destination is discussed.
Get findings into the SOC
projectedSOC analysts need qdash evidence in the search and detection tools they already operate.
Wake the right responders
dry-runSevere findings need escalation rules before live delivery exists.
Hand evidence to auditors
local nowGRC needs a packet today and durable archive paths later.
Verify who owns agents
projectedObserved identities are useful, but ownership gets trusted only after IdP verification.
Move findings into remediation
projectedSecurity findings become accountable when they enter engineering work queues.
Workflow lanes
Another shape: organize the page by where the operator is in the incident/evidence loop. Integrations become exits from that loop, not standalone things to browse.
Open a job, then choose a route
This is the clearest antidote to uncreated-connector clutter. When the operator opens "Get findings into the SOC," Splunk and Sentinel appear because they are candidate routes for that job, with payload previews and blockers attached.
A job-ranked action queue
The action queue is the operational version of the directory. It says which job is blocked, which integration route unlocks it, and whether the next move belongs to the operator or the product.
| Priority | Job | Route | Current proof | Next owner | Action |
|---|---|---|---|---|---|
| 01 | Get findings into the SOC enterprise adoption gate | Splunkprojected | 148,912 events + 9 findings shaped for HEC JSON / OCSF. | product | |
| 02 | Wake the right responders severity routing already exists | PagerDuty + Slackdry-run | 2 pages and 7 messages would have fired this week. | operator + product | |
| 03 | Hand evidence to auditors packet works, archive is next | S3 Icebergprojected | 148,912 append-only events ready for retention. | product | |
| 04 | Verify who owns agents identity confidence affects every page | Okta / Entra IDprojected | 14 observed identities; 4 still need mapping. | customer + product |
The revised framing
The page can still contain the full integration vocabulary, but the first screen should not be a catalog. It should be a job board with a receipt: what is local, what is exportable, what is dry-run, and which downstream job is blocked by missing delivery.