Product Improvement Ticket: Users can't tell if integrations are connected or working after setup

Problem Statement

Users report completing the integration setup process but receiving no clear confirmation, status indicator, or test event to verify whether the connection succeeded. As described in the signal summary, the integration status UI, including pending states, unchanged connect buttons, and absent success indicators, leaves users uncertain whether their workflows are active. This confusion results in repeated reconnection attempts, increased support requests, and erosion of user trust in the platform.

Evidence Summary

The signal summary describes the problem as affecting a large number of users and identifies specific UI deficiencies: pending states that do not resolve visually, connect buttons that appear unchanged after setup, and the absence of green checkmarks or equivalent success indicators. However, it is important to note that this ticket is based on zero empirical evidence items, no support tickets, session recordings, survey responses, or analytics data were provided to substantiate severity, affected segments, or frequency. The confidence score of low (49/100) reflects this evidence gap and means all claims about scale and impact are currently unverified.

Priority Rationale

The signal score of 49/100 with low confidence indicates this is a plausible but unconfirmed problem. Prioritization at this stage is tentative: the described failure mode, users unable to verify integration health, is a high-trust surface area where ambiguity directly undermines platform reliability perception. However, without supporting evidence such as support volume data, drop-off analytics, or user research, resourcing decisions should be deferred until at least one corroborating data source is collected. This ticket should be treated as a discovery-stage item pending evidence validation.

Acceptance Criteria

• After a user completes integration setup, a clear success state (e.g., green status indicator, 'Connected' label, or checkmark) is displayed within the integration UI without requiring a page refresh.
• If an integration connection fails or remains in a pending state beyond a defined timeout threshold, the UI displays a distinct error or pending indicator that is visually differentiated from the success state.
• A test event or connection verification mechanism is available to users post-setup, allowing them to confirm the integration is actively receiving or sending data before relying on it in a workflow.
• The connect button or equivalent CTA reflects the current connection state (e.g., changes to 'Connected' or 'Reconnect' after setup) so users are not left with an unchanged UI that implies no action occurred.
• Post-setup integration status is persistent across sessions, meaning users who return to the integrations page can confirm connection state without needing to re-initiate setup.

Analytics Events to Track

• ·integration_setup_completed, fired when a user reaches the final step of the integration setup flow, used to measure funnel completion and correlate with subsequent reconnection attempts that would indicate the success state was unclear.
• ·integration_reconnect_attempted, fired when a user initiates setup for an integration that is already in a connected or pending state, used as a proxy signal for users who could not confirm their prior connection succeeded.
• ·integration_status_viewed, fired when a user views the integration detail or status page post-setup, segmented by whether the status displayed was 'connected,' 'pending,' or 'error,' to understand which states are most correlated with follow-on confusion behaviors.

Open Questions

1. Is there quantitative data (e.g., support ticket volume, funnel drop-off rates post-integration setup, or session replay signals) that confirms users are actually failing to recognize successful connections, or is this problem inferred from anecdotal reports?
2. Which specific integrations or integration categories (e.g., CRM, webhook, OAuth-based) are most affected by unclear post-setup status, and does the problem vary by integration type or authentication flow?
3. What is the current intended behavior after a successful connection, is a confirmation state designed but broken, or was post-setup feedback never built into the flow?