Establish identity context
Map application users to tenant IDs, roles, groups, and feature entitlements before dashboards are exposed in the UI.
A technical implementation guide for product, engineering, and data teams embedding branded dashboards, governed data access, and customer-facing analytics into a SaaS application.
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.
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.
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.
Use this sequence to move from proof of concept to production without mixing dashboard design, security, and data connectivity into the same workstream.
Map application users to tenant IDs, roles, groups, and feature entitlements before dashboards are exposed in the UI.
Define the approved connection pattern, test query behavior, and document the operational owner for each source.
Mount the Reveal viewer inside the application shell, load the dashboard by ID, and validate rendering across target devices.
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.
// Mount the embedded analytics viewer after the host app validates session state.
import { RevealView } from "reveal-sdk";
const viewer = new RevealView("#analytics-view", {
baseUrl: "/api/analytics",
dashboardId: selectedDashboardId,
theme: "tenant-branded",
canEdit: currentUser.permissions.includes("dashboard:edit")
});
viewer.onDashboardLoaded = dashboard => {
telemetry.track("dashboard_loaded", {
dashboardId: dashboard.id,
tenantId: currentUser.tenantId
});
};
// Keep authorization on the server. The client never decides which data a user can access.
app.get("/api/analytics/dashboards/:id", requireUser, async (req, res) => {
const user = req.user;
const dashboardId = req.params.id;
await entitlementService.assertCanViewDashboard({
userId: user.id,
tenantId: user.tenantId,
dashboardId
});
const dashboard = await revealService.loadDashboard({
dashboardId,
tenantId: user.tenantId,
roles: user.roles
});
res.json(dashboard);
});
// 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
}
};
}
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.
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.
Document which roles can view, edit, export, or administer each dashboard family.
Apply tenant filters server-side so dashboard configuration cannot bypass customer boundaries.
Log access, dashboard load events, export activity, and data source failures for support review.
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.
A dashboard is ready for production only when the implementation team can explain its audience, calculation logic, refresh pattern, permission boundary, and support procedure.
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.
The table below gives support and engineering teams a shared vocabulary for evaluating dashboard behavior before escalating to the platform team.
Use this manual as the baseline for implementation planning, technical review, and documentation standards before embedded analytics reaches production users.