i

Description

Lac d’un bleu turquoise au pied d’un massif rocheux de montagne.

Source

Riddles42 · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

OneLake + SaaS Mobile Apps: Overview

You will be able to define the scope: Power BI reporting whose analytical source is Microsoft Fabric / OneLake, fed by SaaS mobile applications (field SFA/CRM, Dynamics 365…

In brief

• You will be able to define the scope: Power BI reporting whose analytical source is Microsoft Fabric / OneLake, fed by SaaS mobile applications (field SFA/CRM, Dynamics 365, Salesforce, Power Apps, data collection apps).
• You will be able to state the promise of this architecture and its trade-offs (capacity, API quotas, latency, drifting schemas).
• You will be able to say when it's the right choice — and when a simple SQL datamart or Import is enough — with a decision grid and /5 ratings.
• You will have the map of the 3 other files in the folder: architecture, difficulties and pitfalls, AI.
• Volatile facts verified in October 2026; they are marked “(as of 2026-10).”

On this page

1. 1. Interpreting the topic
2. 2. Fundamentals: what OneLake is
3. 3. Fundamentals: what a field SaaS mobile app is
4. 4. The architecture promise
5. 5. SFA and field business use cases
6. 6. In practice: what a typical project looks like
7. 7. When it's the right choice, and when it isn't
   1. It's the right choice if…
   2. It's not the right choice if…
8. 8. Expert: structuring trade-offs
9. 9. Summary ratings
10. 10. See also

Level: 🟢→🔴

1. Interpreting the topic#

The topic “OneLake + SaaS mobile apps” is ambiguous; here is the interpretation used for the entire folder, so that all four files discuss the same thing.

• OneLake refers to the single logical storage layer of Microsoft Fabric: a “OneDrive for data” per tenant, storing tables in open Delta/Parquet format that all Fabric engines (Spark, SQL, KQL, Power BI) read without copying.
• SaaS mobile apps refers to sales force / CRM / field data collection applications run as SaaS: a mobile app (often offline) records visits, orders, readings, photos, signatures; an editor-managed back end syncs them to a cloud that you do not control (Dynamics 365, Salesforce, a vertical SFA solution, a Power App, a forms tool).
• Reporting is Power BI (semantic model + reports), potentially multilingual, reading from OneLake rather than from the app itself.

In other words: “How do I turn data from a SaaS mobile app I don't control into reliable, fresh, and governed reporting, using OneLake?”

For the “managed relational database as source” variant (Azure SQL, SQL Managed Instance, SQL database in Fabric), see the twin folder: SQL Server in SaaS — Overview, and their side-by-side analysis in the comparison.

2. Fundamentals: what OneLake is#

🟢 Novice.

OneLake is the single data lake provided with every Fabric tenant. Four ideas are enough to get started:

1. A single copy. Data is stored once, in Delta Lake format (Parquet files + a transaction log). The SQL engine, Spark, and Power BI read the same files.
2. Items. Data is organized into Fabric items, themselves inside workspaces: a lakehouse (Delta tables + files, mainly handled by Spark), a warehouse (transactional T-SQL warehouse), an eventhouse (time series / events).
3. Shortcuts: a reference to data located elsewhere (another lakehouse, ADLS Gen2, Amazon S3, Dataverse…), accessed as if local, without copying it.
4. Mirroring: continuous replication, managed by Fabric, from an operational database (Azure SQL, Cosmos DB, Snowflake, PostgreSQL, Oracle… (as of 2026-10)) to Delta tables in OneLake.

Power BI connects in three ways: Import (copy into the model), DirectQuery (queries to the source), and Direct Lake (the VertiPaq engine loads Delta columns directly into memory; refresh = simple metadata “reframing”). Details in the architecture file.

3. Fundamentals: what a field SaaS mobile app is#

🟢 Novice.

A field SFA app has four characteristics that drive all reporting:

A weak but decisive signal: perceived freshness depends more on mobile sync (sometimes daily!) than on your pipeline. A “real-time” dashboard fed by tablets that sync in the evening is not real-time.

4. The architecture promise#

🟡 Practitioner.

Combining OneLake and a mobile SaaS app promises:

• An analytical copy you control: historized, queryable in SQL, Spark, or DAX, independent from app query quotas.
• A single platform for ingestion, transformation, storage, semantic model, and reporting: fewer links to monitor, with shared governance and security (OneLake security, GA since spring 2026 (as of 2026-10)).
• Volume at controlled cost: Direct Lake lets you query volumes you would not import, with performance close to Import.
• Adjustable freshness: from daily batch to near real-time (eventstream, mirroring, webhooks) depending on business value.
• A foundation for AI: Copilot, data agents, and notebooks read the same governed data (AI file).

What the promise does not cover: data entry quality, metric definitions (see Semantic Model), SaaS schema stability, adoption by sales reps.

5. SFA and field business use cases#

🟡 Practitioner.

6. In practice: what a typical project looks like#

🟡 Practitioner.

The steps of a reasonable project:

1. Frame the value: 3 to 5 business questions, not “replicate everything.”
2. Inventory the source: objects, volumes, available APIs, quotas, deletion mode, timestamps, documented schema or not.
3. Choose the ingestion mode (see the matrix in the architecture file).
4. Set up medallion layers and quality rules.
5. Model as a star schema (Kimball): visit/order/audit facts, customer, product, date, and field user dimensions.
6. Secure: RLS (sales hierarchy), OneLake security, workspace roles.
7. Industrialize: Git, deployment pipelines, capacity monitoring (CI/CD for data: foundations, datamarts, pipelines, and reports).
8. Acceptance test against known business numbers, then release.

7. When it's the right choice, and when it isn't#

🟡 Practitioner.

It's the right choice if…#

• several sources (SFA, ERP, master data, panel files) must be combined;
• volume or history exceeds what a comfortable Import can handle, or short refresh times are needed;
• you want Spark/Python (advanced cleansing, ML) alongside SQL and DAX;
• the organization is already on Microsoft 365/Entra/Power BI and ready to manage capacity;
• you plan for multiple reports built on the same foundation (one model, multiple uses);
• AI (data agents, Copilot) is part of the roadmap.

It's not the right choice if…#

• a single source with moderate volume feeds 2 reports: direct Import from the SFA connector, or an existing SQL datamart, is simpler and cheaper;
• the team has no skills in Spark/Delta and no upskilling budget: hidden complexity wins out;
• required latency is on the order of seconds and depends on a SaaS that only offers batch;
• the sovereignty or regional constraint does not fit the available Fabric tenant;
• capacity cannot be sized or monitored (no owner).

8. Expert: structuring trade-offs#

🔴 Expert.

1. Copy or not copy. Shortcuts and mirroring avoid physical copying but not dependency: a shortcut to a SaaS exposing files (e.g., Dataverse via Link to Fabric) gives you the vendor's structure, which changes. The medallion approach reintroduces intentional copying to decouple. Rule: never connect a report to a SaaS's raw structure.

2. Shared or dedicated capacity. Fabric cost is a capacity (CU) cost, not a query cost. Shared capacity across nightly ETL, interactive Spark, Copilot, and reports eventually creates pressure: the “noisy neighbor” is internal (difficulties).

3. Timestamps and truth. In an offline SFA, business truth is the event date, technical truth the receipt date. Facts must carry both; “today” aggregates are calculated on the event date, freshness checks on receipt date.

4. Deletions. Most SaaS APIs do not expose deletions cleanly. Without a strategy (soft delete, deletion stream, periodic reconciliation), the lake accumulates ghosts. This is pitfall #1 in these projects.

5. Lock-in. Delta/Parquet are open, so data is portable; however, the Direct Lake semantic model, dataflows gen2, OneLake security, and pipelines are Fabric-specific. Assess your dependency level in the comparison.

6. Governance level. The more self-service there is, the more contracts, certification, and lineage are needed (governance and self-service).

9. Summary ratings#

Expert assessments, contextual (see RATING). Context: BI team of 3 to 6 people, one field SaaS SFA + 2 to 3 complementary sources, 100 to 500 report users, existing Microsoft 365 tenant.

10. See also#

• Continuation of this series: Architecture · Difficulties and Pitfalls · AI
• Relational variant: SQL Server in SaaS — Overview · Comparison — OneLake / Fabric vs Managed SQL Server for Power BI Reporting
• Cross-cutting: Cross-Cutting Power BI Good Practices · Power BI Reporting Project Checklists
• Measure your practice: BI Development Matrix · Operations, Monitoring, and Capacity · Cost, Licensing, and Capacity · Data Quality
• Tools: Source Control for Data: SQL and Power BI
• Terms: Glossary

✻ Written by Claude Sonnet 5.5