The Self-Service Analytics Gap in Microsoft Fabric (And How to Fill It)

TL;DR

Here's what analytics leaders and data teams should know about analytics data workflows. These are the workflows analytics teams use to transform, prepare, and analyze governed data already in the cloud data platform, distinct from the ETL pipelines data engineering teams manage:

• Fabric's architecture serves engineering first: Microsoft Fabric provides powerful infrastructure for data engineering teams managing Extract, Transform, Load (ETL) pipelines, data ingestion, and governance. Analytics teams on the same platform need complementary AI-powered tools for building self-service data workflows.
• Dataflow Gen2 has documented constraints: Fabric's closest analyst-facing option imposes query caps, parameter restrictions, and incremental refresh limitations that limit analytics data workflow development.
• Engineering time is consumed by ad hoc requests: Data workflow requests consume 10–30% of engineering time. For a team of 10 engineers, that equals one to three full salaries spent on slow, ad hoc requests while the business works with stale or untrusted data. What would it mean if analysts could serve themselves without opening a single engineering ticket?
• Organizational structure creates a tradeoff: Centralized analytics models create throughput bottlenecks, while decentralized approaches fragment data quality. Teams need AI-accelerated governed self-service instead.
• Prophecy closes the gap: Prophecy is an agentic data prep platform that lets analytics teams build governed data workflows powered by multiple AI agents. Those workflows compile to production-grade code and run natively on cloud data platforms like Databricks, Snowflake, or BigQuery.

Understanding Fabric's architecture for analytics teams

Every analyst-facing tool in Microsoft Fabric's decision guide mapping requires ETL and SQL knowledge, yet most business analysts focus on turning governed data into insights rather than writing T-SQL or PySpark. That mismatch creates a growing dependency: analytics teams building data workflows (sometimes also referred to as data pipelines), preparing data for analysis, and running ad hoc queries end up submitting tickets to data engineering for work they could handle independently with the right AI-powered tools. The widening queue on one side produces stale data on the other.

Fabric is a powerful infrastructure for data platform teams managing ETL pipelines, data ingestion, and governance. Analytics teams on the same platform have complementary but different needs. They need to transform data, prepare datasets, and iterate on analysis at the speed the business requires, without pulling engineering into every request.

AI-accelerated self-service data workflows that run natively on existing cloud data platforms close this gap. Prophecy, an agentic data prep and analysis platform, enables analytics teams to build governed data workflows independently, within the guardrails data engineering defines and controls, so both teams operate at full capacity on the same platform.

The architecture reflects data engineering priorities

This Fabric architecture guide includes a persona-to-skill mapping to help choose a data integration strategy. Every tool that lists "Business Analyst" as an intended persona requires ETL and SQL knowledge, except database mirroring, which is a passive replication feature with no workflow-building capability.

Dataflow Gen2 limitations reinforce this pattern. Despite the "no-code/low-code" label, the guide lists ETL and SQL as required skill sets alongside data integrators and data engineers. The platform's notebook environment is even more explicit: notebooks are designed for scientists writing code, not for business analysts building data workflows.

Fabric's recommended layering follows a Bronze → Silver → Gold pattern, where data engineers process raw data upstream before analysis begins. This is a sound architecture. Data engineers handle ingestion, governance, and the significant transformation work that belongs in ETL. Analytics teams then work with Gold-layer data that engineering teams have prepared, performing additional transformations for their specific analytics needs.

What documented options are available to analytics teams?

The paths available within Fabric serve data consumption and visualization well, but leave gaps for analytics teams that need to build their own data workflows:

• SQL analytics endpoint: Queries Gold-layer data via a read-only endpoint. This path requires SQL knowledge that most business analysts don't have.
• Power BI reports: Builds reports from pre-built semantic models. BI tools like Power BI are powerful for visualization and analysis, but they depend on well-prepared datasets. Prophecy prepares data so BI tools can deliver on their strengths (and also has visualization features that can help users examine data and insights before deciding if they want to push it to a dedicated BI platform). .
• Dataflow Gen2: Builds dataflows contingent on ETL and SQL understanding. Despite the "low-code" label, the required skill sets are the same as those data engineers use.
• Database mirroring: Replicates data passively with no transformation capability. This feature doesn't support building or modifying data workflows.

Analytics teams frequently need additional data transformation for specific analyses and the ability to iterate on ad hoc queries. That work benefits from AI-accelerated self-service tools designed for the purpose.

Dataflow Gen2's scope for analytics teams

Dataflow Gen2 is constrained as a self-service data workflow tool for analytics teams. While Fabric positions it closest to analyst use, its documented production limits define clear boundaries:

• Query caps: A single instance supports up to 50 queries when staging or a data destination is configured. Moderately complex workflows can hit this ceiling quickly.
• Parameter restrictions: Dataflows with public parameters blocked can't be scheduled or manually triggered via Fabric unless no required parameters are set. This limits automation for any workflow that relies on parameterized inputs.
• Incremental refresh incompatibility: Incremental refresh isn't compatible with parameterized dataflows. Teams that need both capabilities simultaneously face a hard constraint.
• Limited run history: Only the latest run is stored in the Dataflow Staging Lakehouse. Previous runs aren't retained for debugging or auditing.

These constraints compound in practice. A moderately complex data workflow that combines sales data from three systems and applies date-based filtering would likely hit both the query limit and the parameterization constraints simultaneously. Scheduling parameterized dataflows and running incremental refreshes are baseline requirements for any data workflow that needs to run reliably, and analytics leaders managing team capacity feel the impact directly.

Where traditional analytics tools fit in

Many analytics leaders equip their teams with tools like Alteryx to enable self-service data preparation. These tools have supported more independent analytics work and play a role in many organizations' data workflows today.

Cloud data platforms are evolving quickly. Alteryx has been adapting its data preparation platform for the cloud. Its cloud transition is described as ongoing, with deeper integration into platforms like Databricks and Snowflake continuing to develop. Cloud connectivity remains on the company's roadmap.

As Alteryx migrates customers to Alteryx One, its cloud SaaS offering, teams often find reduced capability compared to the desktop tools they're used to, along with increased licensing costs. For teams evaluating their options, the question becomes: what if you could move to a governed, cloud-native solution without retraining your entire team?

Governance and version control vary across tools. Reviewer feedback from 2025 highlights governance considerations, version control differences compared to text-based workflows, and licensing cost factors at scale. These are all considerations analytics leaders weigh when selecting tools for their teams.

Analytics teams increasingly work on cloud data platforms such as Databricks, Snowflake, and BigQuery, where AI-accelerated self-service, native governance integration, and cloud-native deployment complement the data engineering already underway. Prophecy is typically used alongside other data tools, and for teams with existing Alteryx workflows they want to bring into Databricks or Snowflake, Prophecy's transpiler makes that migration straightforward, with no need for a disruptive rip-and-replace.

The challenge is the organizational structure

The core challenge is structural, not technical. Centralized analytics models create throughput bottlenecks, decentralized approaches fragment data quality, and both leave engineering absorbing work that could be handled elsewhere. Data workflow requests consume a fraction of engineering time. This equals a couple of full salaries spent on slow, ad hoc requests while the business works with stale, slow, or untrusted data, affecting tooling, team structure, and delivery speed simultaneously.

Centralized analytics creates bottlenecks within teams and leads to a lack of business buy-in. In one documented case, missing data architecture threatened to stall transformation projects during multiyear transformation timelines.

Self-service analytics falls short of expectations today at delivering expected impact, with governance, trust, accuracy, scalability, and adoption cited as the failure dimensions. A systemic pattern of shortcuts across data workflows persists, where teams skip data quality and upstream validation steps. Handing five people ungoverned AI code-generation tools without standardization is like giving them a mixed pile of train-set parts with no instructions and asking each to build a track. They won't match, and the outputs can't be governed.

Analytics leaders need AI-accelerated, governed self-service, where analytics teams build data workflows independently, within guardrails defined and controlled by data engineering.

How Prophecy enables AI-accelerated self-service analytics

Prophecy is an agentic data prep and analysis platform that lets analytics teams build governed data workflows on cloud data platforms. It runs on top of your existing cloud data platform, after data engineers have already ingested and governed the data. Unlike legacy tools that lock you into their governance model, Prophecy keeps compute, governance, and security in your stack. Your platform team retains full control, which is a very different conversation than asking IT to adopt someone else's infrastructure.

Prophecy was described as a rare combination of technical depth, user-centric design, and enterprise-grade controls, earning recognition in the Data Management: Pipelines category. That combination works in practice through a few specific capabilities.

Multiple AI agents turn intent into governed data workflows. Users describe their business goal to an AI-powered workflow they can inspect, refine, and validate. Multiple AI agents handle different tasks,e.g. renaming columns, filtering rows, updating join conditions, or transforming data for a specific analysis. Every step is visible and reviewable, combining AI acceleration with human review and standardization.

Data workflows compile to production-grade code. What analysts build visually compiles to code: open-source SQL with full Git versioning, Continuous Integration and Continuous Delivery (CI/CD) support, and lineage tracking. You get the speed of AI with the reliability of engineering. No proprietary formats, no vendor lock-in, and no engineering rewrites needed to deploy. Git retention means no code-scanning tools are required.

Governance flows from your existing controls. On Databricks, for example, Prophecy integrates with Unity Catalog so AI agents inherit user permissions. Access controls defined in your catalog apply automatically. Data engineering teams set guardrails on what agents can do, and analytics teams work within those boundaries without needing to think about compliance because the platform enforces it.

Data engineering stays in control without staying in the critical path. Data platform teams define catalogs, schemas, access policies, and approval processes. AI agents operate under governance, following your standards and your approval process. When data workflows encounter issues, the failing operator highlighted view gives analysts context and an AI-suggested fix rather than a stack trace.

The business wants fast, trusted, accurate data, and analysts want to deliver it without waiting on engineering. With Prophecy's AI-accelerated data prep, analysts build and run governed data workflows themselves, on your cloud platform, within your guardrails. The analyst becomes the hero. The business gets what it's been asking for. Engineering stops being the bottleneck.

Every workflow built in Prophecy is one more proof point for the platform they've built. Try Prophecy for free to see how it fits into your existing stack.

Build AI-accelerated self-service data workflows with Prophecy

Analytics teams need to prepare data, build data workflows, and iterate on analysis independently, without waiting in engineering queues or sacrificing governance. Most teams start with the efficiency use case: a faster, better way to build and manage data workflows alongside what already exists. Your team stays productive, you avoid betting everything on a big-bang rollout, and when the value is clear, broader adoption follows naturally. Prophecy is an AI-accelerated data prep and analysis platform that enables exactly this, working alongside your existing cloud data platform and the data engineering tools already in place.

The following capabilities make this possible in practice:

• Agentic AI with multiple AI agents: Describe what you need in plain English and Prophecy's AI agents build, refine, and validate data workflows step-by-step, handling data transformation, preparation, and ad hoc queries across the workflow.
• Workflows backed by real code: Every data workflow compiles to open-source SQL with full Git versioning, CI/CD support, and lineage tracking. AI acceleration combines with human review, standardization, and Git retention.
• Automated data workflow deployment: Schedule, orchestrate, and monitor data workflows with built-in error diagnostics and AI-suggested fixes. No engineering tickets required.
• Cloud-native on your existing platform: Runs natively on cloud data platforms like Databricks, Snowflake, or BigQuery and inherits your catalog permissions, access controls, and governance policies automatically.

Analytics leaders are identifying the productivity gap and looking for a better path. Data platform leaders want efficiency, data quality, and something their engineering team can trust and govern. Prophecy speaks to both: agentic, AI-accelerated data prep that makes analysts self-sufficient and gives platform teams full visibility and control.

With Prophecy, analytics teams build production-grade data workflows faster, governed and scalable on the cloud data platform your organization already manages. The people who need to see Prophecy are the analysts and platform teams who will actually use and govern it. Analysts see how quickly they can move; platform teams see that governance and compute remain entirely under their control. Book a demo to see the difference.

Frequently asked questions

How does Microsoft Fabric's architecture relate to analytics team needs?

Fabric is designed for data engineering: ETL pipelines, ingestion, and governance. Analytics teams working downstream on governed data benefit from complementary AI-accelerated tools purpose-built for self-service data workflows.

What are Dataflow Gen2's limitations for analytics data workflows?

Documented query caps, parameter scheduling restrictions, incremental refresh incompatibility with parameterization, and limited run-history storage constrain its use as a reliable self-service data workflow tool.

How does Prophecy work alongside existing data tools?

Prophecy runs after data engineers have ingested and governed data on cloud data platforms like Databricks, Snowflake, or BigQuery. Analytics teams use Prophecy's AI agents to build data workflows on that governed data independently. For teams with workflows they want to pull into Databricks or Snowflake, the transpiler makes migrating from tools like Alteryx straightforward.

What makes Prophecy's approach to AI-powered self-service different?

Multiple AI agents power each step of the data workflow, from data transformation to deployment. AI acceleration combines with human review, standardization, and Git retention, so you get the speed of AI with the reliability of engineering while inheriting governance from your existing cloud data platform.