Solution Atlas
SpecialisedUser storyConsultative playbook

Our SaaS customers want self-service analytics in our product

The product team wants to ship customer-facing analytics inside the SaaS product. The engineering question is build vs embed; the commercial question is per-tenant isolation vs shared capacity; the governance question is how to expose data without losing control.

Trigger
Customer feature request; product roadmap commitment.
Good outcome
Power BI Embedded live in the product, per-tenant isolation pattern, capacity sized to forecast.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Product roadmap includes customer-facing analytics
  • ·Engineering debating build vs embed
  • ·Multi-tenant SaaS with per-tenant data isolation requirements
  • ·Existing dashboards built for internal users — not productised
  • ·Customers asking for self-service over their own data

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.What analytics are your customers asking for — fixed dashboards, self-service exploration, or both?

    WhyDrives the embedding pattern. Fixed dashboards are simpler; self-service needs more isolation work.

    Listen for: “they want to slice their own data” · “fixed reports are not enough any more” · “enterprise customers want SQL access”

  2. 2.How is your SaaS deployed — multi-tenant single database, database per tenant, or hybrid?

    WhyDetermines the isolation pattern. Database-per-tenant is easier for embedded analytics; shared database needs row-level security.

  3. 3.What is the commercial model — analytics included in base tier, paid add-on, or per-seat add-on?

    WhyDrives the capacity model. Per-tenant capacity for enterprise tier; shared capacity for SMB tier.

  4. 4.Have you sized the workload — concurrent users at peak, dataset size per tenant, refresh cadence?

    WhyCritical for Fabric capacity sizing. Underestimating the workload is the most common embedded-analytics failure mode.

  5. 5.Who supports analytics issues — your product team, customer support, or a dedicated analytics function?

    WhyDrives the operational model. Embedded analytics generates a support load that needs to land somewhere.

  6. 6.What governance posture must customers see — GDPR, SOC 2, residency commitments?

    WhyShapes the architecture. EU customers may require EU-only capacity; regulated industries may require dedicated capacity.

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

Customer-facing analytics either absent or built in-house by the engineering team. Engineering owns dashboard maintenance, data refresh, and per-tenant performance issues. No clean isolation pattern — customer dashboards run on the operational database with predictable performance impact. Product roadmap commits new analytics features but engineering capacity is the constraint.

Typical concerns

  • ·Engineering team building dashboards instead of product features
  • ·No clean per-tenant isolation pattern
  • ·Performance impact on the operational database
  • ·Cannot scale to self-service without exposing too much
  • ·Customers ask for SQL access — no defensible way to provide it

Capability gaps

  • ·Embedded analytics platform with per-tenant isolation
  • ·Capacity model that maps to commercial tiers
  • ·Row-level security pattern for shared-database tenants
  • ·Self-service exploration with governance
  • ·Support model for customer analytics issues
Target architecture

Microsoft Fabric hosts the analytics substrate with capacity sized per commercial tier. Power BI Embedded surfaces dashboards inside the SaaS product via app-owns-data embedding. Row-level security isolates tenants on shared capacity; dedicated capacity for enterprise tier with isolation guarantees. Self-service exploration available on the higher tiers via Power BI report authoring with sandboxed workspaces per tenant. Support model defines who owns customer analytics issues. Engineering shifts back to product features.

Key capabilities

  • App-owns-data embedding
  • Per-tier capacity model
  • Row-level security for tenant isolation
  • Sandboxed self-service per tenant
  • Support and SLA model

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.Tenant isolation pattern — shared capacity + RLS vs dedicated capacity per tenant vs hybrid

    Shared capacity + RLS

    When it fitsSMB tier; high tenant count, low per-tenant volume; cost-efficient.

    Trade-offsRLS configuration risk; noisy-neighbour performance variability.

    Dedicated capacity per tenant

    When it fitsEnterprise tier; isolation guarantees commercially valuable; per-tenant performance SLA.

    Trade-offsCapacity cost per tenant; operational overhead.

    Hybrid — shared for SMB, dedicated for enterprise

    When it fitsMixed customer base with tiered commercial model.

    Trade-offsTwo-track operational model.

    Default recommendationHybrid — shared capacity with RLS for SMB tier; dedicated capacity for enterprise tier as a commercial differentiator.

  2. Decision 2.Embedding pattern — app-owns-data vs user-owns-data vs hybrid

    App-owns-data

    When it fitsSaaS pattern — the customer never sees Power BI directly; the product brokers all access.

    Trade-offsAll authorisation logic lives in the product; Power BI licence count attached to the product, not customers.

    User-owns-data

    When it fitsCustomers are Power BI users in their own right; federated identity.

    Trade-offsEach customer needs a Power BI tenancy; complex licensing.

    Hybrid — app-owns for embedded, user-owns for export

    When it fitsMost enterprise customers — embedded for in-product, export for their own analytics teams.

    Trade-offsTwo integration paths.

    Default recommendationApp-owns-data for the trial. Add user-owns export for enterprise tier in phase two.

  3. Decision 3.Self-service depth — fixed dashboards only vs report authoring vs full DAX

    Fixed dashboards only

    When it fitsSMB tier; complexity not commercially justified.

    Trade-offsCustomers ask for "just one more chart" and you cannot deliver at scale.

    Report authoring (Power BI Desktop-like)

    When it fitsEnterprise tier; customers have analyst capacity.

    Trade-offsSandbox per tenant needed; support load rises.

    Full DAX + dataset access

    When it fitsPower-user enterprise tier; customers have BI teams.

    Trade-offsHeavy support load; commercial value must justify.

    Default recommendationFixed dashboards for SMB; report authoring for enterprise tier; full DAX only as a premium add-on for sophisticated customers.

Low-risk trial — proof of value

90-day embedded analytics trial for two customer cohorts

12 weeks

Fabric capacity sized to the trial workload (F8 typical for trial). Power BI Embedded integrated into the SaaS product via app-owns-data. Five fixed dashboards available to all trial customers. RLS pattern enforced for tenant isolation. Two enterprise trial customers given report-authoring sandbox to validate self-service. Capacity utilisation, query latency, and support ticket volume measured continuously. Commercial pricing model validated against actual capacity consumption.

Success criteria

  • Embedded dashboards live in the product for two cohorts (SMB + enterprise)
  • Tenant isolation validated by security review
  • Query latency under 2s at the 95th percentile across the trial
  • Commercial pricing model validated against measured capacity cost

InvestmentFabric F8 capacity + Power BI Embedded + product engineering integration effort. Estimated ~€6–12k/month for the trial scope. Existing customer-facing analytics (if any) continue in parallel.

Proof metrics

  • ·Embedded analytics adoption rate >40% of trial customers
  • ·Capacity cost per tenant within commercial pricing tolerance
  • ·Support ticket volume per tenant within plan
  • ·Two enterprise customers validate self-service exploration as a buying differentiator

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Power BI Embedded is the in-product analytics surface. App-owns-data embedding is the SaaS pattern — the product brokers access and the customer never sees Power BI directly.

Why for this story

Fabric capacity sizes to commercial tiers — shared for SMB, dedicated for enterprise. The capacity model is the architecture lever that maps engineering cost to commercial price.

Back to Embedded & external analytics