Developer Documentation

Reveal Embedded Analytics Integration Manual

A technical implementation guide for product, engineering, and data teams embedding branded dashboards, governed data access, and customer-facing analytics into a SaaS application.

Embedded Analytics Integration Manual

AIAPISDKBI

Purpose and audience

This manual documents the integration path for embedding Reveal dashboards into a production SaaS product. It is written for implementation teams that need clear ownership across authentication, data source configuration, dashboard lifecycle, permissions, deployment, and operational support.

Architecture

How the embedded analytics layer fits into the application

Reveal is designed to be embedded inside a host application rather than linked as a separate reporting destination. The application remains responsible for identity, tenant context, entitlement checks, and user experience. Reveal provides the analytics runtime, dashboard model, visualization layer, and SDK surface.

Integration model

The cleanest implementation separates the customer-facing UI from the server-side authorization path. The client requests dashboards through the host application. The backend validates user context, creates the Reveal view model, and returns only the analytics experience the user is permitted to access.

  • Host app: Authentication, tenancy, navigation, entitlement logic.
  • Reveal SDK: Dashboard rendering, visualization interaction, viewer events.
  • Data layer: Governed connections, query execution, row and tenant controls.
Host App tenant context Reveal SDK viewer runtime Dashboards models and UX Authorization Service roles, claims, row filters Data Sources SQL, REST, files, cloud data
Quickstart

Minimum viable implementation sequence

Use this sequence to move from proof of concept to production without mixing dashboard design, security, and data connectivity into the same workstream.

1

Establish identity context

Map application users to tenant IDs, roles, groups, and feature entitlements before dashboards are exposed in the UI.

2

Register data sources

Define the approved connection pattern, test query behavior, and document the operational owner for each source.

3

Embed the viewer

Mount the Reveal viewer inside the application shell, load the dashboard by ID, and validate rendering across target devices.

Technical writing sample

Implementation examples developers can use directly

The following examples show how the manual communicates exact integration behavior. Each sample includes enough context for engineering review while keeping the surrounding instructions readable for product and implementation stakeholders.

tenant-filter-pattern.js
// Apply tenant-aware filters before data is returned to the embedded dashboard.
function buildRevenueQuery(context) {
  return {
    sql: `
      SELECT month, region, product_line, revenue
      FROM analytics.revenue_summary
      WHERE tenant_id = @tenantId
        AND region IN (@allowedRegions)
      ORDER BY month DESC
    `,
    parameters: {
      tenantId: context.tenantId,
      allowedRegions: context.allowedRegions
    }
  };
}
Implementation

From concept to production release

The implementation plan should be documented as a dependency chain. Dashboard configuration depends on data availability. Data availability depends on security rules. Security rules depend on tenant and user models that the host application already owns.

Pre-integration checklist

  • Confirm the host application has a stable user identity model.
  • Define tenant isolation rules and identify any shared-data scenarios.
  • Inventory dashboards by audience, permission level, and data source.
  • Document development, staging, and production connection strings.

Release checklist

  • Verify dashboard load time under expected concurrent usage.
  • Test cross-tenant access boundaries with negative test cases.
  • Validate dashboard behavior on desktop, tablet, and narrow viewport layouts.
  • Document escalation paths for data freshness or visualization errors.
Governance

Access control must be designed before dashboard creation

Embedded analytics security is most reliable when the application treats dashboards as governed product features. The dashboard view should inherit the same identity, entitlement, and audit model as the rest of the application.

A

Role-aware dashboard access

Document which roles can view, edit, export, or administer each dashboard family.

B

Tenant-aware data isolation

Apply tenant filters server-side so dashboard configuration cannot bypass customer boundaries.

C

Audit-ready operation

Log access, dashboard load events, export activity, and data source failures for support review.

Dashboard authoring

Create dashboards with documented intent

Every production dashboard should have an owner, a target audience, a decision purpose, and a maintenance rule. Without those controls, dashboards tend to accumulate duplicate measures, conflicting filters, and unclear visual language.

Dashboard documented intent Audience who uses this view Decision what action it supports Maintenance owner and update cadence

Dashboard acceptance criteria

A dashboard is ready for production only when the implementation team can explain its audience, calculation logic, refresh pattern, permission boundary, and support procedure.

  • Label measures clearly: Use business-readable terms and include units where relevant.
  • Control export behavior: Match export access to the user role and tenant policy.
  • Review data freshness: Show the last refresh timestamp where stale data creates user risk.
Operations

Make data source behavior visible to the implementation team

Operational documentation should identify how each data source behaves under load, how failures appear to the user, and which team owns remediation. This prevents analytics support from becoming an undocumented engineering escalation.

Data source record

  • Connection type and authentication method.
  • Refresh frequency, caching policy, and freshness SLA.
  • Known query limitations and timeout thresholds.
  • Owner, backup owner, and escalation channel.

Support triage record

  • User, tenant, dashboard ID, widget name, and timestamp.
  • Browser, device, and application version.
  • Expected result, actual result, and screenshot if available.
  • Recent deployment or data pipeline change.
Troubleshooting

Fast diagnosis for common implementation issues

The table below gives support and engineering teams a shared vocabulary for evaluating dashboard behavior before escalating to the platform team.

Dashboard does not load

  • Check route authorization and dashboard entitlement.
  • Confirm dashboard ID exists in the target environment.
  • Review console errors for missing SDK assets or blocked requests.

User sees incorrect data

  • Validate tenant ID in the server request context.
  • Inspect row-level filters passed to the query layer.
  • Confirm cache scope is tenant-aware and not shared incorrectly.

Embed analytics with governance built in

Use this manual as the baseline for implementation planning, technical review, and documentation standards before embedded analytics reaches production users.

Request received. A Reveal specialist would follow up with implementation details.