Workspace Outbound Access Protection (OAP) for Operations Agent and Fabric Maps (Preview)
Co-authors: Andre Terceros and Bodhisatva Gautam Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps WS admins secure outbound connections from workspace items to external resources. Administrators can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules. As organizations adopt AI-powered operations at scale, governance and security remain at critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent and Fabric Maps, enabling workspace administrators to control the outbound actions an agent can perform. OAP for Operations Agent When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions. Figure: Outbound Access Protection helps workspace administrators govern outbound Operations Agent actions while providing clear visibility when actions are blocked. What's new with Operations Agent and OAP? With Outbound Access Protection support for Operations Agent, workspace administrators gain more control over how agent-initiated actions interact with external services and resources. The following updates improve governance, visibility, and operational oversight while helping organizations continue to automate with confidence. Govern outbound agent actions through workspace-level OAP policies. Control whether Operations Agent can send Teams notifications based on allowed connections. Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access. Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences. Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log. Figure: Activity Log Operations Details show the steps the agent completed and each action’s status, including when an action is blocked. OAP for Maps Fabric Maps can connect to a variety of data sources, including Lakehouse across Fabric workspaces, Kusto databases (KQL), Ontologies as well as external geospatial services such as Web Map Services (WMS), Web Map Tile Services (WMTS), and Web Feature Services (WFS). Workspace Outbound Access Protection helps organizations maintain security and compliance by governing outbound connections and requiring explicit approval before a map can access external resources. With OAP enabled, Fabric Maps follows a "default deny" model, ensuring only approved destinations can be accessed. How it Works When Workspace Outbound Access Protection is enabled on a workspace, Fabric Maps evaluates outbound connectivity at multiple stages: Save and Load Operations Whenever a map is created, updated, or loaded, Fabric evaluates all referenced data sources against the workspace policy. If a data source isn't permitted: References are blocked Disallowed sources are redacted when the map is opened Attempts to save unsupported references are rejected Runtime Data Access Map visuals continuously retrieve data such as: Map tiles Geospatial features Query results Before each outbound request is executed, Fabric validates the destination against the workspace's outbound access protection policy. External Service Validation External geospatial services such as WMS, WMTS, and WFS are validated through Data Movement and Transformation Services (DMTS). DMTS acts as a policy enforcement layer and ensures only explicitly approved external endpoints can be reached. Supported Connection Scenarios Lakehouse Lakehouse connectivity receives the most flexibility under the current release. Lakehouse within the same workspace are always allowed. Lakehouse in other workspaces can be allowed using Data Connection Rules. Administrators maintain granular control over cross-workspace access. External Geospatial Services Organizations can securely connect to approved WMS, WMTS, and WFS services. By using Data Connection Rules with the Geospatial Web Services connection type, administrators can create an allow list of approved endpoints. This enables scenarios such as: Accessing enterprise GIS systems Consuming approved mapping services Integrating with external geospatial data providers Kusto Databases and Ontologies Connections to Kusto databases and Ontologies within the same workspace continue to function normally. Cross-workspace connectivity for these sources is currently blocked when OAP is enabled. Future releases will introduce additional policy controls for these connection types. Configuring Fabric Maps with Workspace OAP Enabling protection is straightforward: Enable Workspace Outbound Access Protection for the workspace. Create Data Connection Rules that define approved destinations. Add approved external geospatial services using the Fabric connection experience. Configure Geospatial Web Services rules to authorize required endpoints. Once configured, Fabric Maps can access only the approved destinations specified by policy. Security by Design Workspace OAP for Fabric Maps follows several key security principles: Explicit Allow Lists: Only approved destinations can be reached. All other outbound connectivity is automatically blocked. Consistent Enforcement: Policies are applied during authoring, loading, and runtime execution, ensuring continuous protection throughout the lifecycle of a map. Fail-Closed Protection: If policy validation services become unavailable, Fabric denies cross-workspace connections by default. This fail-closed behavior helps prevent unintended data exposure during service disruptions. What’s next? We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon in GA soon. Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community Learn more Workspace outbound access protection overview Outbound Access Protection for Operations Agent (Preview) Workspace Outbound Access Protection for Fabric Maps
Capacity Operation Events in Real-Time Hub (Preview)
Capacity Operation Events in Real-Time Hub is now available as a preview, giving Microsoft Fabric capacity administrators access to detailed, operation-level telemetry in near real time. Capacity Operation Events build on Capacity Overview Events by helping administrators move beyond understanding overall capacity health to identifying the specific operations, workspaces, and artifacts contributing to capacity consumption, throttling, and performance issues. From capacity health to root cause analysis Capacity administrators have long relied on tools such as the Capacity Metrics App to understand utilization patterns and investigate capacity-related issues. This augments those capabilities by providing direct, near real-time access to the underlying operational signals. It exposes granular telemetry for individual operations running on a Fabric capacity, enabling organizations to: Identify the operations driving capacity consumption. Investigate throttling delays and performance bottlenecks. Understand which workspaces and artifacts contribute to capacity pressure. Correlate workload activity with capacity utilization trends. Build custom monitoring, governance, and automation solutions using Fabric Real-Time Intelligence, including the use of Microsoft Activator for designing automated triggers with no code. Together with Capacity Overview Events, administrators now gain both a high-level and detailed view of capacity behavior: Capacity Overview Events help answer: What is happening to my capacity? Capacity Operation Events help answer: Which operations are causing it? Deep operational visibility Capacity Operation Events provide detailed telemetry for individual operations executed on a Fabric capacity. Each event includes information such as workspace and item details; capacity unit consumption; operation duration; operation start time and smoothing window attribution. This enables administrators to quickly answer questions such as Which refreshes consumed the most capacity yesterday? Which operations experienced throttling delays? Which operations are contributing most to capacity pressure? Administrators can in turn translate these insights into actions: Create alerts when high-cost operations exceed defined thresholds. Detect and investigate throttled workloads in near real time. Trigger automated notification and/or remediation workflows. Stream operational telemetry into Eventhouse for historical analysis and retention. Build custom dashboards tailored to your monitoring and governance needs. Integrate capacity telemetry into existing operational platforms and workflows. Getting started For complete schema and event details for operation events, see the Explore Fabric capacity operation events in Fabric Real-Time hub documentation. You can also learn more about overview events in the Explore Fabric capacity overview events in Fabric Real-Time hub documentation. The Capacity Events Accelerator GitHub repository is also available as an even easier way to get started with capacity events.Choosing your medallion pattern in Fabric Data Warehouse
Coauthor: Artur Vieira Part one of a series on medallion architecture with Fabric Data Warehouse. Medallion architecture is one of the most common patterns for organizing data in Microsoft Fabric, but successful implementations require a series of design decisions — from choosing the right architecture pattern to securing, governing, and optimizing your workloads. In this five-part series, we'll walk through the practical choices that shape a modern medallion implementation in Fabric Data Warehouse (DW), sharing recommendations, tradeoffs, and real-world guidance along the way. In this installment, we'll focus on the first and most important decision: choosing the right medallion pattern for your workload. Why this matters Most teams designing a medallion architecture in Microsoft Fabric start with the wrong question: "Should I use a Lakehouse or a Warehouse?" The better question is, "How much Spark do I actually need?" Your answer will shape everything from development workflows to security and long-term maintenance. Quick level-set: medallion organizes data into three layers — Bronze (raw), Silver (enriched), and Gold (curated) — to progressively improve data quality and structure. That’s the whole definition you need. The interesting part is how you map those layers onto Fabric. The key decision: Data Warehouse, Lakehouse, or both? Fabric gives you two major analytics storage options on OneLake: Lakehouse and Data Warehouse. Because Fabric DW is an enterprise-scale SQL warehouse built on the open Delta Lake format in OneLake — combining a relational SQL engine with lake storage, so data is stored as Delta Parquet with ACID transactions and time travel — you don’t have to choose between “warehouse” and “lake.” You’re really choosing how much of the pipeline you run in T-SQL versus Spark. That leads to two patterns worth recommending: an all-in-one or hybrid approach. Pattern A: All-in-One Data Warehouse Use Fabric DW for Bronze, Silver, and Gold, separated by schemas (for example Bronze.*, Silver.*, Gold.*) or by separate warehouses, with data flowing raw → curated entirely within the warehouse using T-SQL or Data Factory pipelines. Best when: most of your data is structured (or can be structured on load) and your team prefers SQL-centric development. Why it’s nice: one engine, one skill set, transactions and views for every hop. Pattern B: Lakehouse + Warehouse Hybrid Land raw data in a Lakehouse for Bronze (and optionally Silver), where you can use Spark for complex prep, then implement Gold in the Warehouse as the SQL serving layer for BI. This works seamlessly because OneLake underpins both — Silver or Gold data can be materialized to Delta tables and queried by the Warehouse’s SQL endpoint without copying. Best when: You have unstructured or semi-structured data, or need heavy data engineering in Python or Scala. Why it’s nice: The right engine for each layer — Spark for heavy prep, T-SQL for serving — with no data copying, since OneLake underpins both Which should you pick? Here’s the rule I’d give a customer: Rule of thumb: For most SQL-focused analytics teams, an all-in-one Fabric Data Warehouse is the pattern I’d recommend starting with. If you have a mix of unstructured data or need heavy data engineering, land and refine raw data in a Lakehouse, then serve the final Gold layer from the Warehouse. Fabric’s architecture lets you evolve, so you’re not locked in: start all-in-warehouse and add a Lakehouse later when a new source needs Spark, or vice versa. All-in-One DW Lakehouse + DW Hybrid Primary skill T-SQL Spark / Python + T-SQL Best for data Structured / relational Unstructured, semi-structured, streaming Bronze lives in Warehouse staging tables Lakehouse (raw files, delta tables or both) Gold lives in Warehouse Warehouse Pick it for Simplicity, one engine Flexibility, heavy engineering One layout rule, whichever pattern you choose Keep layer separation clear. Microsoft recommends isolating layers into different workspaces, or at least different Fabric items, for better control and governance. The payoff is real: separate items give you finer security control — only data engineers touch Bronze while analysts see only Gold — and clearer isolation, so an accidental change in Gold can’t affect Bronze. Takeaway Don’t frame this as “Warehouse vs. Lakehouse.” Frame it as “How much Spark do I need?” If your workloads are structured and SQL-first, choose an all-in-one DW. If they’re unstructured or engineering-heavy, choose a hybrid approach, with Gold always served from the Warehouse. As your implementation grows, consider separating Bronze, Silver, and Gold into distinct Fabric items or workspaces to simplify governance and security. Ready to go deeper? Explore the Microsoft Fabric documentation for Data Warehouse and OneLake, then stay tuned for Part 2 of this series, where we'll walk through howBronze, Silver, and Gold layers are implemented in practice. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline In the next post, we'll explore what Bronze, Silver, and Gold layers actually look like in Fabric Data Warehouse and how data moves between them.
Event-Driven Copy Job Execution with Fabric Activator (Generally Available)
Introduction Modern data platforms are increasingly moving toward event-driven architectures where data flows react to events or changes instead of running on rigid schedules. In Microsoft Fabric, two powerful capabilities enable this vision: Copy job: the simplest and most scalable way to move data across multiple clouds and tenants. Activator: a real-time engine that monitors data and reacts to events. A key enhancement brings these two capabilities closer together: you can now invoke Copy jobs directly from Activator—no pipeline required. This unlocks a simpler, faster, and more efficient way to build event-driven data movement in Fabric. Why this matters The limitations of scheduled data movement Traditionally, data movement in enterprise systems relies on fixed schedules: Run every five minutes Run every hour Run daily While simple to set up, this approach introduces several challenges: Inefficient execution (empty runs): Most scheduled jobs run even when no data has changed, leading to unnecessary computing usage and cost. Latency tradeoff: Running more frequently increases cost, while running less frequently increases data latency. Operational overhead: Managing schedules across hundreds or thousands of tables can quickly become complex and difficult to maintain. Activator + Copy Job: A natural fit What customers need is simple: Move data only when something happens or changes. For example, when a table in OneLake is updated or when a new file lands in storage. This is exactly the scenario where Data Activator shines. Activating data movement based on events is a natural combination of these two capabilities: Activator monitors data and detects events Copy job moves data efficiently across systems With this new capability, you can now connect them directly, enabling true event-driven data movement without introducing additional orchestration layers. Quick tutorial: Set up Activator to invoke a Copy job Step 1: Create a Copy job Define your source and destination Choose full or incremental copy Configure mappings and settings Step 2: Create an Activator rule Select a data source (e.g., OneLake, Eventstream, monitoring data) Define a condition: File created Table updated Metric threshold reached Step 3: Configure the action Choose “Invoke Copy job” Select the target Copy job Step 4: Start the rule Once enabled: Activator continuously monitors the defined condition When the condition is met → the Copy job runs automatically Data is moved only when needed, with no unnecessary runs. Learn More What is Copy job How to create a Copy job How to monitor a Copy job Submit feedback on Fabric Ideas and join the conversation in the Fabric Community. Questions or feedback? Leave your thoughts in the comment section.Simplify your data movement with Copy job: CDC with SQL estate (Generally Available)
Author: Ye Xu, Principal Program Manager - Copy job is the go-to solution in Microsoft Fabric Data Factory for simplified data movement across multiple clouds and tenants. With native support for bulk copy, incremental copy, and change data capture (CDC) replication, it can handle a wide range of movement scenarios through an intuitive, easy-to-use experience.Simplify data movement with Copy job: more control, more flexibility
Author: Ye Xu, Principal Program Manager - Copy job is the go-to solution in Microsoft Fabric Data Factory for simplified data movement across multiple clouds and tenants. With native support for bulk copy, incremental copy, and change data capture (CDC) replication, it can handle a wide range of movement scenarios through an intuitive, easy-to-use experience.
Outbound access protection for Data Factory (Generally Available)
Co-author: Abhishek Narain Workspace outbound access protection (OAP) is widely accessible for Data Factory workloads—including Pipelines, Copy Job, and Dataflows—as well as for Mirrored Databases such as Mirrored SQL Database and Mirrored Snowflake. Key benefits Enhanced outbound security: By leveraging OAP rules, organizations can ensure that the Data Factory items from the protected workspace can only connect to trusted endpoints allowed by workspace admins. All the other outbound connections to public internet and other destinations are blocked from the workspace. Granular control: Control outbound access per workspace. This allows you to apply differentiated controls across business units, environments (dev/test/prod), data domains, or project. Data exfiltration prevention: Workspace OAP when combined with Inbound protection can help the customer prevent the data from exfiltrated outside the workspace boundary. Better compliance: Meet stringent compliance and regulatory requirements by ensuring your sensitive data never leaves the workspace boundary if it’s not allowed by Workspace Admins. Additional functionalities Exploratory APIs in pipelines and Copy Job: APIs used for Browse, Preview, and Test Connection operations will support outbound access protection. Copy job in OAP will support Datawarehouse as destination. Workspace level granularity for Notebook and Spark Job Definitions connection types. Machine Learning Models and Experiments are supported with outbound access protection. Data Agent and Eventstreams are now supported with outbound access protection in preview. To learn more about Workspace OAP for Data Factory, set-up scope and limitations, refer to the Workspace outbound access protection overview documentation and Workspace outbound access protection for Data Factory documentation. What’s next? We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon. Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community.
From restricted to AI-ready: Preparing unstructured data directly in Microsoft Fabric with Tonic Textual (Generally Available)
If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. AI teams need to move quickly, but the reality is that most of the data they need simply isn’t ready for AI. In fact, Gartner predicts that through 2026, 60% of AI projects will be abandoned because they lack AI-ready data. A large portion of enterprise information exists in unstructured text. This includes support tickets, contracts, call transcripts, documentation, and internal communications. These sources often contain information that can help train or evaluate AI systems. However, they also include sensitive data such as personal identifiers, financial details, or confidential business information. Because of this, access to these datasets is often restricted. Tonic Textual (Generally Available) as a workload in the Microsoft Fabric Workload Hub. The workload helps teams detect sensitive information in text and prepare datasets that can be used in AI development workflows inside Fabric. For the official announcement, read the press release - Tonic.ai Announces General Availability of Tonic Textual for Microsoft Fabric. Unlocking unstructured data for AI development Many organizations already manage structured data for analytics in Fabric. Unstructured text can also provide useful information for AI systems. For example, in healthcare, information such as clinical notes, discharge summaries, physician documentation, and patient communications often contain context that structured datasets do not capture. These sources can support use cases such as knowledge retrieval, clinical documentation analysis, or internal search tools. However, they may include protected health information, which limits how the data can be used in development environments. Preparing this data before it is used in AI systems allows organizations to reduce privacy risk while still using the information contained in these documents. Tonic Textual workload provides tools to identify and transform sensitive information so that unstructured datasets can be used more safely in AI workflows within Fabric. Preparing unstructured data inside Fabric Tonic Textual runs as a workload within Microsoft Fabric. It scans unstructured files stored in Microsoft OneLake and detects sensitive entities such as names, identifiers, or financial information. Organizations can configure how these entities are handled, options include: Redacting sensitive values Masking specific identifiers Replacing values with synthetic data Applying custom rules for specific entity types Prepared datasets can then be used in AI development workflows, including model training, evaluation, and application development with Microsoft Foundry. Running these steps inside Fabric allows teams to prepare text data without moving it outside the platform. Preparing text for AI workflows When sensitive entities are transformed, it is important that the text remains usable for downstream tasks. Tonic Textual preserves document structure and surrounding context when transformations are applied. For example: Support conversations can keep their dialogue format. Contracts can keep their structure and clauses. Documentation can retain technical context. This helps teams prepare datasets that can be used in training, testing, or retrieval scenarios. Applying the same transformation rules across datasets also helps organizations use consistent privacy policies across development workflows. Example workflow in Fabric Teams can use Tonic Textual in Fabric as part of their existing data workflows. 1. Add the workload: Install Tonic Textual from the Microsoft Fabric Workload Hub. Figure: Tonic Textual in Fabric Workload Hub. 2. Select data in OneLake: Choose document collections, transcripts, or other text datasets stored in OneLake. Figure: Select source folder in OneLake. 3. Select an output location: Choose where the prepared dataset should be written in OneLake. This allows teams to keep the original source data unchanged while creating a separate AI-ready dataset. Figure: Select destination folder in OneLake. 4. Detect sensitive entities: Tonic Textual scans the dataset and identifies sensitive information. Figure: Scan the files for sensitive text. 5. Configure transformations: Select how each entity type should be handled. Figure: Configure de-identification preference. 6. Use the prepared data: The resulting dataset remains in Fabric and can be used in downstream pipelines such as training or retrieval systems. This approach allows teams to prepare text datasets before they are used in prompts or models. For a quick end‑to‑end walkthrough of this flow in action, check out the Tonic Textual on Microsoft Fabric video. Available now Tonic Textual for Microsoft Fabric can be added directly from the Fabric Workload Hub. If you are building AI with unstructured data and need a secure way to prepare sensitive text for production, you can start using Tonic Textual Fabric Workload now!Integrating Dynamics 365 Business Central with Microsoft Fabric using Open Mirroring with BC2Fab workload (Generally Available)
If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. Overview Integrating Dynamics 365 Business Central with Microsoft Fabric is a common requirement as organizations modernize their analytics platforms. The primary challenge is not connectivity, but establishing an architecture that scales predictably, protects the ERP system, and enables analytics teams to focus on insights rather than maintaining ingestion pipelines. In this post, we'll cover how the BC2Fab Fabric Workload from Navida can be used to replicate Business Central data into Fabric using an Open Mirroring architecture. Problem statement Business Central and Fabric are designed for different types of workloads. Business Central supports transactional processes such as accounting, purchasing, inventory, and order management. Fabric is designed for analytical workloads such as reporting, data science, and AI. When organizations use traditional ingestion patterns between these systems, several challenges often appear: Fabric capacity usage increases when ingestion pipelines perform heavy transformations. Refresh times grow as data volumes and customizations increase. Production ERP environments experience additional load from analytical queries. Data teams spend time maintaining pipelines instead of building analytics solutions. These challenges often appear when solutions move from pilot environments into production. Organizations therefore benefit from an architecture that keeps ingestion predictable and allows analytics workloads to run independently. Architecture overview The BC2Fab Fabric Workload provides an integration layer between Dynamics 365 Business Central and Microsoft Fabric. Business Central data is replicated into Microsoft OneLake, the unified storage layer in Fabric. Once the data is stored in OneLake, it can be accessed through Fabric experiences without creating additional copies. The architecture separates data replication from analytics workloads so that ERP systems remain focused on transactional operations while analytics runs in Fabric. Figure: BC2Fab Fabric Workload Architecture The architecture consists of four main layers: Business Central (source system): Business Central stores operational and financial data used by the organization. Data is retrieved through APIs or read-only replicas to avoid impact on transactional workloads. BC2Fab Fabric Workload (replication layer): The BC2Fab Fabric Workload from Navida synchronizes Business Central data into Fabric using incremental change detection. It manages table replication, metadata configuration, and schema updates. OneLake storage (data layer): Replicated data is stored in OneLake using open storage formats. Because OneLake is shared across Fabric workloads, the same dataset can support multiple analytical scenarios. Fabric engines (analytics layer): Once the data is available in OneLake, teams can build analytics solutions using Fabric experiences such as Data Engineering, Data Warehouse, and Microsoft Power BI for reporting and AI/Copilot scenarios built on ERP data. Using Business Central data in Fabric Once Dynamics 365 Business Central data is available in Microsoft Fabric, analytics teams can begin building reporting and analytical solutions on top of the replicated datasets. Common scenarios include: Financial reporting and profitability analysis Sales and revenue performance tracking Inventory and supply chain monitoring Customer and product analytics Because the data is stored in Microsoft OneLake, it can also be combined with other datasets already present in Fabric. This allows organizations to extend ERP reporting with additional operational or analytical data sources. What clients say Organizations using the BC2Fab Fabric Workload have shared their experiences after implementing the solution in Microsoft Fabric environments. The following perspectives highlight how teams are using Business Central data in Fabric for analytics and reporting. “BC2Fab deployed to a production workspace in Fabric—no more time spent wrangling data into tables or managing multiple Gen2 dataflows. I can now focus on using Fabric, trusting my Business Central data is already there. Even large Business Central tables—including custom extension fields and tables with 165M rows were available far earlier than planned thanks to metadata-driven configuration. Within the first week, this translated into real, measurable improvements across both daily operations and month-end processes." - Richard Swift, Finance Systems Manager, Enable Networks Limited (New Zealand) “Getting Business Central data into Fabric used to be a headache. After the 2023 SQL Server Konferenz we searched everywhere for a reliable approach—until the BC2Fab Workload for Fabric finally solved it. Fast setup, no oversized capacity, and most importantly: it just works. Stable, low‑maintenance, and exactly what a critical data pipeline need. Now our engineers can focus on modeling, analytics, and insights instead of fighting ingestion and sync issues” - Steffen Genz, Head of Business Analytics at AXRO GmbH (Germany) “I have been using Business Central for years, but BC2Fab allows me to become data driven. I can get all the insights I need to make the right decisions.” - Frank Glockzin, Managing Director, Glockzin (Germany) Now available The BC2Fab Fabric Workload from Navida is available for organizations that want to replicate Dynamics 365 Business Central data into Microsoft Fabric. Organizations adopting Fabric for analytics can use the workload to bring ERP data into OneLake and begin building reporting and analytical solutions on top of Business Central data.
