Microsoft Fabric Fabric & Power BI - FAQs

Yes — Fabric can coexist with existing Power BI and Azure investments. Fabric does not require ripping out existing Power BI investments; it extends them. Existing Power BI Pro licences continue to work, existing reports continue to run, and the migration path from Power BI Premium to Fabric capacity is well-documented. Existing Azure data investments (ADF, Synapse, Azure SQL, Storage) can be progressively migrated to Fabric or kept where they are with Fabric reading from them. The transition is incremental rather than a forklift replacement, which suits mid-market budgets and risk appetite.

Yes — Hopton can build the architecture without delivering the reports. Some clients engage us for the data engineering and architecture workstream specifically, with the reporting and visualisation handled by their internal team or another partner. The architectural deliverables (lakehouse structure, ingestion pipelines, semantic model design, deployment pipelines) are independent of the report build. The engagement scope is flexible. We are equally willing to deliver the full stack or a specific layer.

Real-time can sometimes replace daily reporting, for the right use cases. The high-frequency operational dashboards benefit from real-time. The strategic management reporting (monthly P&L, quarterly board pack) does not. The right pattern is a layered approach: real-time dashboards for operational decisions, refreshed-hourly dashboards for tactical management, and traditional batch reporting for strategic and statutory needs. Trying to put everything on real-time produces an expensive and unnecessary platform; trying to use only batch produces lost operational opportunities. Both have a place.

No, you do not need to replace Power BI or Fabric to use AccoTool, because it sits on top of the estate you already have and extends it with a planning and writeback layer. Nothing about your existing reporting or data platform is torn out. Planning simply inherits the same governance, security and single source as your reporting, which makes the Fabric and Power BI investment you have already made more valuable. Hopton connects AccoTool to that foundation as part of implementation.

Yes - Hopton does implement real-time analytics. Real-time and streaming analytics is part of our delivery scope when client use cases justify it. We have built real-time operational dashboards, supply chain visibility, and event-driven monitoring on Fabric Real-Time Intelligence. The team holds the relevant Microsoft certifications and has practical experience with the workload. Real-time is not the bulk of our work (most mid-market analytics is batch-led) but it is a capability we deliver when the use case is right.

To start a conversation about real-time analytics, email us at hello@hoptonanalytics.com with a brief description of the use case (what decision needs to be made faster, what events need to trigger action, what data sources are streaming-capable), and the current state of your data platform. The first conversation is exploratory and free. If there is a fit, we propose either a focused real-time scoping engagement or a broader analytics engagement that includes real-time alongside batch.

To visualise MBA rules in Power BI, three views work well. A rule table sorted by lift, showing the top rules with their measures. A network graph showing the strongest associations as edges between items, useful for understanding the structure of the relationships. A category heatmap showing aggregate association strength between categories rather than individual items. The right view depends on the audience: buying teams use the rule table, range planners use the network graph, leadership uses the heatmap. Power BI handles all three.

Power BI surfaces the forecast for business users through dashboards combining actuals, forecasts, and accuracy. The standard views include: forecast versus actual over time, accuracy metrics by SKU group and horizon, exception views showing SKUs with the largest forecast errors, and the planning view showing the forecast as input to the operational plan. Different audiences use different views: planners use the SKU-level detail, leadership uses the aggregate trends, finance uses the accuracy metrics for forecast credibility. Power BI handles all the views from the same underlying data.

Power BI works well on Databricks. Power BI connects to Databricks SQL through the standard connector and works fine. The integration is solid. The difference compared to Fabric is the same as Snowflake: it is two systems working together rather than one unified system. For BI-led organisations, the integration tax is real but manageable. For organisations where BI is one of many concerns, it is rarely the deciding factor.

Purview integrates natively with Fabric and Power BI. Sensitivity labels applied in Purview propagate to Fabric workspaces, semantic models, and Power BI reports. Lineage tracks data movement across the analytical estate. Classification rules apply consistently. The integration is one of the genuine advantages of staying within the Microsoft ecosystem; equivalent integration with non-Microsoft governance tools requires more work. For Microsoft-stack mid-market analytics, Purview is usually the right governance tool.

A real-time engagement differs from a batch one in three ways. The use case definition matters more, because real-time has higher costs and tighter benefits. The architectural design is more complex, with eventstream routing, eventhouse design, and Data Activator rules to specify. The operational model is different, with streaming-specific monitoring and recovery patterns rather than batch retry logic. The engagement timeline can be similar (eight to twelve weeks for a focused real-time implementation) but the discovery and design phases are usually more involved.

Real-time fits alongside existing batch analytics through a unified architecture where batch and streaming feed the same lakehouse, with each workload using the data through whichever path suits the latency requirement. Batch analytics reads Gold-layer Delta tables for traditional reporting. Real-time analytics queries eventhouses for streaming dashboards and Data Activator for event-driven actions. The two coexist on the same Fabric capacity, sharing storage in OneLake, sharing governance through Purview, and sharing identity through Entra ID. Real-time is an extension of the platform, not a separate platform.

Real-time fraud detection works through Data Activator rules monitoring transaction streams for patterns that indicate fraud. The patterns are usually combinations: unusually high transaction amount, unusual location, unusual time, or unusual frequency relative to the customer's history. When the rule triggers, Data Activator routes the event to the fraud team for review or, in tightly-scoped automated cases, takes immediate action (hold the transaction for review). The trust framework matters here particularly: false positives cost customer relationships, false negatives cost actual money. Conservative threshold setting and human review on the marginal cases is the right pattern.

The Power BI/Fabric forecast integrates with your planning system as an input rather than a replacement: most mid-market businesses with serious supply chain operations use a dedicated planning system (RELEX, Anaplan, o9, Slimstock, similar) for the actual planning workflow. The Fabric forecast feeds the planning system as input. The pattern: Fabric generates statistical forecasts, the planning system adds management adjustments, the result becomes the operational plan. The integration is bidirectional: actuals flow back from the planning system into Fabric for accuracy tracking and model refinement. The integration architecture is straightforward but requires deliberate design.

Real-time differs from batch in three structural ways, from a data engineering point of view. Batch processes accumulated data on schedule; streaming processes individual events as they arrive. Batch tolerates failure with retry; streaming requires careful state management to avoid losing or duplicating events. Batch performance is measured in throughput; streaming performance is measured in latency. The skills, the tools, and the operational model differ. Most data engineering teams need to learn streaming separately from batch; they are not interchangeable.

Yes — real-time analytics is often overkill for mid-market businesses. The honest assessment for many mid-market businesses is that 'real-time' requirements turn out to mean 'within an hour' or 'within a day', which standard batch refresh patterns handle. The cost of building real-time architecture (development effort, infrastructure cost, operational complexity) is substantial; the cost should be justified by genuine business need rather than by the technical novelty. We have built real-time platforms for clients where the use case justified it; we have also recommended against real-time investment for clients where batch was sufficient.

Most mid-market implementations use batch CDC at intervals of minutes to hours. Real-time CDC (where changes flow continuously into the platform) is achievable through Fabric's eventstreams and Real-Time Intelligence workload but is overkill for most analytical use cases. The right interval depends on the business need: customer-facing operational dashboards may justify minute-level CDC, monthly management reporting works fine on overnight CDC. Choose deliberately rather than defaulting to real-time.

Whether anomaly detection should run in batch or real-time depends on the use case. Finance integrity work usually runs in batch (overnight or weekly review of recent transactions). Operational monitoring usually runs in real-time or near-real-time (the value is in catching the issue while it is still recoverable). Customer behaviour monitoring varies. Most mid-market implementations include both: batch detection for periodic review with deeper analysis, and real-time detection for high-stakes immediate response. The Fabric architecture supports both within the same platform.

Real-time data should sometimes be stored separately from batch data, depending on the use case. High-volume time-series data (IoT, application logs, audit events) lives best in eventhouses with Kusto-style optimisation. Streaming data that needs to be combined with batch data for unified reporting lives best in lakehouse Delta tables. Many real-time implementations route the same source events to both, with the eventhouse serving real-time queries and the lakehouse serving combined batch and streaming analytics. The decision is per source; the architecture supports both patterns.

Real-time intelligence in Fabric is available, but used selectively in mid-market. The Real-Time Intelligence workload supports streaming data from event sources (IoT devices, application telemetry, transactional systems) with KQL-based analytics on top. The use cases that pay back are narrow: live operational dashboards where the value is in seconds rather than minutes, anomaly detection on fast-moving data, and event-driven workflows. Many mid-market 'real-time' requirements turn out to mean 'within an hour', which is usually fine on standard Fabric refresh patterns rather than streaming.

An operational real-time dashboard is live views of operational KPIs refreshed continuously rather than on schedule. Examples include call centre dashboards showing live queue depth and agent status, warehouse dashboards showing live picking rates and order status, retail dashboards showing live till activity by store, and supply chain dashboards showing live shipment positions. The value is the ability to act on developing situations: a queue building, a warehouse falling behind, an unusual sales pattern emerging. Power BI dashboards on Direct Lake against eventhouse data deliver the live view.

Real-time means three different things in practice, and the distinction matters. True real-time means data flowing continuously with latencies measured in milliseconds to seconds. Near real-time means data flowing in micro-batches with latencies measured in seconds to minutes. Operational reporting often described as real-time means refresh cycles of minutes to hours. The right answer depends on what the business needs. True real-time is appropriate for operational systems, fraud detection, and IoT. Near real-time covers most operational dashboards. Anything an hour or longer is batch, regardless of what the requirements document calls it.

Real-Time Intelligence in Microsoft Fabric is the Fabric workload for streaming and event-driven analytics. It includes eventstreams (for ingesting streaming data), eventhouses (for storing time-series and event data), KQL queryset (for querying the data), and Data Activator (for triggering actions based on events). The workload is built on Microsoft's Azure Data Explorer (Kusto) technology, mature and battle-tested at hyperscale within Microsoft's own services. Real-Time Intelligence is one of the six core Fabric workloads alongside Data Factory, Data Engineering, Data Warehouse, Data Science, and Power BI.

Yes — Hopton will recommend against real-time when batch is sufficient. Real-time is one of the technologies most often over-specified in scoping conversations because it sounds modern. Our discovery work usually surfaces whether the requirements genuinely need real-time or whether near-real-time batch would deliver the value at much lower cost. We have written scoping reports recommending against real-time investment; the recommendation costs us a more complex engagement and earns trust for the simpler one we deliver instead.