1. Executive Summary
Integration Data Health addressed a trust problem: users and operational teams needed clearer ways to understand whether integration data was actively syncing and when action was needed.
This work connects directly to observability, monitoring, system status, and operational workflow design.
2. System Context
The core user question was:
Is my integration working?
The system needed to connect raw technical signals to understandable health states across many integration types, product features, expected sync patterns, operational surfaces, and user-facing integration surfaces.
Conceptual progression:
Signal collection -> Status visibility -> Operational alerting -> User-facing guidance
3. The Real Problems
Users had limited visibility into whether an integration was actively syncing data. Silent failures could affect workflows and business outcomes before anyone noticed.
Operational teams also needed better ways to reason about integration health without relying only on engineering investigation.
Health definitions varied by feature and vendor, so the model needed to be vendor-agnostic while still useful enough to guide action.
4. Design Principles
- Start with the user's trust question.
- Status should describe system behavior in human terms.
- Operational visibility can be deeper than user-facing communication.
- Health states need clear thresholds and next actions.
- Observability UX should reduce ambiguity without creating false certainty.
- Strategic vision should translate into operational milestones.
5. Major Decisions
Define A Vendor-Agnostic Status Model
The model needed to work across many integrations and feature-specific signals. The design direction focused on overall and per-feature health, last successful sync, expected frequency, and understandable degraded or broken states.
Separate Operational And User-Facing Visibility
Operational tools could expose deeper diagnostic context. User-facing marketplace surfaces needed simpler, action-oriented status that helped people understand whether something was healthy, degraded, disabled, or broken.
Treat Alerting As A Progression
Rather than jumping directly to user-facing alerts, the model progressed from signal collection and visibility toward operational alerting and then user-facing guidance.
6. System Evolution
This began as broad Data Health and Observability vision work, then moved into smaller milestones that could clarify health, status, and actionability one surface at a time.
Phased model:
Observability vision
-> Integration health model
-> Operational visibility
-> User-facing status
-> Alerting and actionability
7. Collaboration Model
This work required close engineering partnership because the signals were technical. The design role was translating data-flow behavior into status models, marketplace concepts, operational concepts, and clearer product and engineering decisions.
8. Results
Product outcomes:
- Defined models for integration health, status, sync visibility, and operational/user-facing observability.
- Helped translate a broad observability direction into clearer phased product decisions.
Qualitative outcomes:
- Improved visibility into system state.
- Clarified how teams could reason about degraded or broken integrations.
- Created a clearer troubleshooting path from signal to status to action.
- Helped teams discuss health definitions using shared product language.
9. Reflection
The key lesson is that trust in platform systems depends on visibility. Users do not only need a connection to exist; they need to know whether it is working, when it last worked, and what action is appropriate when it degrades.
Good observability UX is not just about exposing backend signals. It is about turning signals into confidence, prioritization, and next steps.
10. Reusable Patterns
- Signal -> status -> alert models.
- Operational vs user-facing visibility.
- Healthy / degraded / broken states.
- Last successful sync context.
- Expected frequency models.
- Feature-level health.
- Trust-centered status design.
- Vision-to-phased-execution translation.
11. Lessons That Carried Forward
This work is a continuation of the integration platform foundation and data ingestion work. First, the platform needed reusable setup and configuration patterns. Then, as integrations became operational infrastructure, users needed health, status, troubleshooting, and trust.
