DP-600 Voucher
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hi everyone, I recently passed the DP-700 Microsoft Fabric Data Engineer Associate certification and am now planning to take DP-600 (Microsoft Certified: Fabric Analytics Engineer Associate) while the Fabric concepts are still fresh in my mind. Unfortunately, I wasn't able to use a previous DP-600 voucher when I first received it as I wasn't ready for the exam at the time. I was wondering if anyone is aware of any current voucher opportunities for DP-600, or has an unused voucher that they won't be using and is transferable (if permitted by the voucher terms). Any guidance would be greatly appreciated. Thanks in advance! Regards, Amanul
Microsoft Fabric Materialized Lake Views (MLVs) – Looking for Confirmation on a Few Points
Microsoft Fabric Materialized Lake Views (MLVs) – Looking for Confirmation on a Few Points Hi everyone, I'm currently working with Materialized Lake Views (MLVs) in Microsoft Fabric and trying to establish the right approach for implementing them in a proper Dev → UAT → Production setup. I have gone through the available documentation, but I would appreciate confirmation from people who are already using MLVs in real projects. MLV Refresh Failure and Monitoring My current understanding is that if an MLV fails during its initial execution or during a scheduled refresh: The MLV run will be marked as Failed. The failure can be investigated through the MLV run history/monitoring experience. The error code, error message and execution details can be used for troubleshooting. If an upstream MLV fails, dependent MLVs may be skipped. Questions: Is there a recommended/native way to send an email or Teams notification whenever an MLV refresh fails? What is the recommended production monitoring approach for MLV refresh failures? Is anything else required in addition to configuring the MLV schedule? ON MISMATCH FAIL vs ON MISMATCH DROP My current understanding is that ON MISMATCH is related to handling schema/structure mismatches encountered during MLV processing, rather than being a general data-quality validation mechanism. For example: ON MISMATCH FAIL would cause the MLV operation to fail when the applicable mismatch occurs, whereas: ON MISMATCH DROP would allow processing to continue while dropping the affected/incompatible data. Questions: Is this understanding correct? What exactly constitutes a "mismatch" for an MLV? What are the recommended scenarios for using FAIL vs DROP? Does ON MISMATCH FAIL affect the entire MLV refresh or only the affected data/operation? Dev → UAT → Production Deployment This is probably my biggest area of uncertainty. Suppose I create and test the following in DEV: DEV Workspace Lakehouse Source tables MLV 1 MLV 2 My expectation is that I should not manually recreate the MLVs in UAT and Production. Instead, I would use Fabric lifecycle/deployment capabilities to promote the artifacts: DEV → UAT → PROD Questions: Are MLV definitions currently supported for this type of Dev → UAT → Prod deployment? Does Deployment Pipeline automatically handle the corresponding Lakehouse/item dependencies? If the workspace names, Lakehouse names and item IDs are different between environments, how are those references handled? Does Fabric automatically rebind supported dependencies to the corresponding target-environment resources? Which MLV-related properties/configurations need to be manually configured or validated after deployment? For example: DEV Workspace: BI_DEV Lakehouse: Sales_LH_DEV ↓ UAT Workspace: BI_UAT Lakehouse: Sales_LH_UAT ↓ PROD Workspace: BI_PROD Lakehouse: Sales_LH_PROD How much of this environment-specific mapping is automatically handled by Fabric? MLV Refresh Schedules Across Environments Suppose my DEV MLV has a refresh schedule of every 1 hour. When I deploy it to UAT and Production: Is the schedule also deployed? If it is, can or should it be different between environments? What is the recommended approach for managing MLV schedules separately in DEV, UAT and PROD? Is schedule configuration considered part of the deployable MLV artifact or environment-specific configuration? MLV Dependencies / MLV on top of MLV Can we create an MLV that references another MLV? For example: Source Tables → MLV 1 – Silver → MLV 2 – Gold → MLV 3 – Aggregation Is this a supported and recommended architecture? If yes: Are there any limitations on the number or depth of MLV dependencies? How does refresh orchestration work? If MLV 1 fails, are MLV 2 and MLV 3 automatically skipped? How is the dependency and lineage handled during deployment from DEV → UAT → PROD? SQL View on top of MLV Can we create a regular SQL View on top of an MLV? For example: Source Tables → Materialized Lake View → SQL View → Semantic Model / Power BI If this is supported: Are there any performance implications? Does the SQL View remain virtual while the MLV remains materialized? Is this a recommended pattern for exposing MLV data to downstream consumers? View → MLV Conversely, can an MLV be created on top of a regular SQL View? For example: Source Tables → SQL View → MLV If supported, are there any restrictions around the types of views or queries that can be used as an MLV source? Recommended Production Architecture For a production implementation, would the following architecture be considered a reasonable pattern? Source Tables → MLV Layer → Silver MLVs → Gold MLVs → SQL Views (if required) → Semantic Model → Power BI Or is it generally better to consume MLVs directly from the semantic model where possible? General Best Practices For anyone using MLVs in production: What are the main limitations you have encountered? What should be considered when designing MLV dependencies? How do you handle monitoring and alerting? How do you manage Dev/UAT/Prod deployment? Are there any MLV-specific CI/CD considerations that are easy to miss? What would you recommend avoiding when designing an MLV architecture? I'd particularly appreciate confirmation from anyone who has implemented MLVs across multiple Fabric environments such as DEV, UAT and PROD. Thanks in advance!
ADLS Gen2 and OneLake - Choosing the right storage approach
As Microsoft Fabric adoption grows, a practical architecture question follows: how does OneLake relate to Azure Data Lake Storage Gen2 (ADLS Gen2), and do we need to migrate? Both store analytics data in open formats, but they offer different ways to manage and consume it. I would start with the workload and the investments already in place, rather than with a decision to move storage. For an established lake, keeping ADLS Gen2 and exposing selected data to Fabric may be the simplest path. For a new Fabric-centric workload, storing data directly in OneLake may reduce operational work. The useful unit of decision is a layer or data product, not the entire estate. Start with the operating model What ADLS Gen2 is designed for ADLS Gen2 brings analytics capabilities to Azure Blob Storage through a hierarchical namespace. In this PaaS model, Azure runs the storage service while your team manages accounts, containers, networking, lifecycle policies and access through Azure role-based access control and POSIX-style ACLs. It can hold any file format, giving teams flexibility to choose how different engines process the data. That flexibility is valuable when ingestion pipelines and multiple analytics engines already share a lake. Azure Databricks, Azure Machine Learning and other compatible tools can work with the data where it is. The architectural responsibility sits with the team: bringing storage, processing, discovery and governance together into an operating platform. OneLake: Fabric-managed data lake Built on ADLS Gen2, OneLake is created automatically for a Fabric tenant. Microsoft manages the underlying storage infrastructure, while teams organize and secure data through workspaces and items such as Lakehouse’s. This SaaS model shifts the day-to-day focus from storage accounts to analytics data products. OneLake stores physical data and can also reference data elsewhere through shortcuts. The benefit becomes tangible in the way Fabric workloads work together. Spark notebooks prepare Lakehouse data, SQL analytics experiences expose supported tables, and Power BI can consume suitable tables through Direct Lake. A Lakehouse’s Files area can hold any file format, while its Tables area serves supported table formats and engines, including Delta and supported Iceberg tables through metadata virtualization. Shared storage simplifies integration, while each engine still has its own supported capabilities. The architectural relationship The storage hierarchy is straightforward: tenant, workspace, then data item. Within a Lakehouse, Tables and Files support different consumption needs. Domains group workspaces for organizational ownership and governance, rather than adding a folder level to the storage path. A simple example is: Scope Illustrative organization Fabric tenant OneLake namespace Workspace Reporting workspace containing a Sales Lakehouse Lakehouse Tables Local Delta tables, or a shortcut to supported Gold tables in ADLS Gen2 Lakehouse Files Files and folders, including supported external shortcuts What changes for analytics consumers Shortcuts: Bring existing data into reach A plain shortcut references an internal or external storage location without requiring an ingestion copy. If curated Delta tables already live in ADLS Gen2, a supported Lakehouse Tables shortcut can make them available to Fabric consumers. Files shortcuts expose files instead; making those files into queryable tables is a separate step. This provides an incremental adoption path, although downstream workloads may still cache or materialize data. The access design deserves as much attention as the data path. An ADLS shortcut uses the source connection’s configured credentials alongside Fabric permission checks. It does not automatically carry each reader’s source ACLs into Fabric. Before sharing it, I would check least privilege, network reachability and table compatibility with the identities and workloads that will use it. Shortcut transformations address a different need: preparing data for consumption. Supported CSV, Parquet and JSON transformations use Fabric Spark to copy and convert source content into managed Delta output and keep it synchronized. That can simplify preparation, but it introduces compute, output storage and synchronization to operate. Choose a plain shortcut when referencing the existing data is enough; choose a transformation when the output itself adds value. Direct Lake: Simplify the BI data path Direct Lake loads requested Delta-table columns into VertiPaq memory without requiring a full Import-mode refresh. Metadata refresh, also called framing, still determines the data version available to the model. The practical benefit is a simpler BI data path for suitable workloads. Capacity, table optimization, security and model design still determine performance and freshness. The underlying Delta data can remain in ADLS Gen2 when exposed through a supported OneLake Tables shortcut. That is the bridge to Direct Lake, rather than a direct connection from the semantic model to an ADLS path. I would assess the intended Direct Lake mode and security design, then test representative queries and freshness requirements before making performance commitments. Governance: Discovery and enforcement both matter Governance needs both business context and effective access control. ADLS Gen2 can use Microsoft Purview for discovery and governance alongside its storage permissions. In Fabric, the OneLake catalog brings discovery, metadata, lineage and endorsement into the analytics experience, while workspaces and items provide ownership context. Those capabilities help people find and understand data; the permissions on the actual access path determine who can use it. I would compare security and lifecycle requirements against the specific design, rather than assume one platform always offers more control. Fabric supports tenant- and workspace-level private links and customer-managed keys with supported-item constraints. OneLake also supports lifecycle policies and hot, cool and cold tiers. The decision turns on whether the required workload, connector, encryption and network configuration work together, not simply whether a feature appears on a checklist. AI readiness starts with usable data Both approaches can support AI. ADLS Gen2 is a supported Azure Machine Learning datastore, so an established lake may already be a sound foundation. Fabric adds integrated preparation and consumption options that can be useful without relocating that lake. My starting question would be which capability the team needs and where the data is already well governed. For example, AI-powered shortcut transformations can turn supported .txt files into Delta output containing summaries, translations, sentiment, redacted PII or extracted entities. A team could summarize eligible text sourced from ADLS and analyze the results in Fabric. This capability is in public preview, with regional and capacity requirements. Output quality and sensitive-data handling still need evaluation; automated redaction alone cannot establish compliance. Interoperability depends on the integration path Snowflake illustrates why the integration path matters. Fabric Mirroring can replicate Snowflake-managed table data into OneLake. For Iceberg tables in supported object storage, shortcuts and metadata virtualization provide another route; the Snowflake Iceberg mirroring path uses metadata mirroring and storage shortcuts. These are different architectural choices, with different implications for copies, freshness and ownership. Snowflake on Azure can also write Iceberg tables to OneLake in supported configurations. That integration requires public connectivity, does not support private-link workspaces, and has same-region prerequisites for writes. Azure Databricks can read and write OneLake through authenticated ABFS paths, with compute and authentication requirements. Open formats help, but the chosen engine and network design still need to fit the supported integration. Make the choice layer by layer An existing Databricks lake: should Bronze and Silver move? Consider a team with reliable Azure Databricks pipelines and Bronze, Silver and Gold layers in ADLS Gen2 that now wants Fabric reporting. My recommendation would be to keep the working Bronze and Silver layers unless there is a separate business or technical reason to move them. For Gold, there are two useful starting points. Keep physical Gold in ADLS Gen2 and expose supported Delta tables through Lakehouse Tables shortcuts. Gold becomes available in Fabric without physical move. I would start here when existing storage contracts, authoritative writers and non-Fabric consumers need to remain intact. Alternatively, write or materialize selected Gold data directly in OneLake when Fabric ownership or service-level requirements justify changing the pipeline. Databricks can support this pattern through authenticated ABFS access with the appropriate compute configuration. Moving selected Gold products can be a focused decision, independent of any future Bronze or Silver migration. For either pattern, agree on the authoritative writer, table compatibility, effective permissions, freshness targets, monitoring and total cost. A storage shortcut does not transfer Unity Catalog authorization, so test the security model with representative readers. These responsibilities matter more than whether the diagram shows one lake or two. Count the governance and semantic-model work I would also count the work above storage. A team may maintain security rules and semantic logic in Databricks, then recreate them for Fabric reporting. Repeating policies, metrics, relationships and business definitions creates maintenance and testing work, with a risk of drift whenever requirements change. Reducing that duplication can be a stronger reason to adopt a shared consumption layer than saving a data copy. A useful pattern is to use Databricks for data preparation, make governed Gold data available through OneLake, and use Fabric as the shared consumption layer. OneLake security can centralize data-access policies across supported Fabric engines and access paths. Separately, a deliberately shared Power BI semantic model lets reports and compatible clients reuse measures, relationships and business definitions instead of rebuilding them. These are two distinct opportunities to reduce downstream work: common access control and an explicitly reusable semantic layer, not benefits that storage alone creates. That semantic model reuse does not require moving your Gold layer: supported shortcuts can expose ADLS data, and shared Power BI models can also use other supported sources. OneLake does not automatically unify Unity Catalog policies nor give every Databricks or Spark workload the same semantic layer. Where Unity Catalog remains authoritative, I would evaluate supported integrations and ask: where are policies and metrics defined, which engine enforces them under which identity, which consumers reuse the model, and who maintains and tests necessary differences? A practical guide Your situation Starting point What to validate Successful multi-engine lake; established account/API dependencies Keep ADLS Gen2 as an authoritative store Existing contracts, source security and the specific Fabric access path New Fabric-centric analytics and shared Fabric items Use native OneLake storage Ownership, supported workloads, capacity, security and lifecycle requirements Mixed estate; selective Fabric adoption or duplicated governance and model logic Combine ADLS Gen2 and OneLake; assess a shared consumption layer See the mixed-estate checklist below. A required security or storage feature determines the design Compare the exact supported configurations Connector and workload limits, private networking, CMK item coverage, retention and total cost For a mixed estate, validate: Data access: shortcut compatibility versus materialization. Write ownership: the authoritative writer. Operations: freshness targets and monitoring. Security: effective identities and policy enforcement. Semantics: reuse of a shared semantic model. Governance ownership: who maintains and tests necessary cross-platform differences. Coexistence as a practical starting point Use ADLS Gen2 where its customer-managed storage model and existing integrations serve the workload well. Use native OneLake where Fabric’s managed model and shared analytics experiences provide a clear benefit. For an existing estate adopting Fabric, I would usually start by connecting the two and move data only where the benefit is clear. Coexistence can be a transition or a lasting design; consolidation should earn its place through workload requirements and measurable value.
From SAP, FSM and SharePoint silos to a Fabric Lakehouse: Medallion + Direct Lake
We recently moved a building-services client at DataToBiz off a reporting setup where data sat across SAP S/4HANA, SAP FSM, SharePoint, and flat files. Pulling together a single report meant manual extraction and reconciliation, with some reporting cycles taking up to two weeks. We rebuilt this on Microsoft Fabric. Dataflows Gen2, Pipelines, and Notebooks handle ingestion from the four source types through automated batch workflows, landing in a single Lakehouse on OneLake with a Bronze/Silver/Gold structure. Spark notebooks and pipelines handle large-scale transformation, cleansing, and KPI standardization across the source systems. Power BI semantic models with DAX and RLS handle role-based access. Reports use Direct Lake mode to work with data in OneLake without the traditional import-based refresh approach. Result: reporting went from 10–14 days to under a day, with 20+ reports automated across roughly 60 users. The interesting part wasn't just bringing the data into Fabric. It was standardizing KPIs when different enterprise systems represented the same metric differently. Question for the group: how are you handling KPI standardization when multiple enterprise systems define the same metric differently? If anyone has a scalable, metadata-driven approach for that, please share.
OAP for MLVs cross workspace
Hi all, I have a question regarding OAP implementation across multiple workspaces. My current setup consists of three layers: Bronze: OAP enabled Silver: OAP enabled Gold: OAP not enabled In the Bronze layer, I extract all source data using specific endpoints and gateways, with the required connection rules configured. In the Silver layer, I use shortcuts to access the source lakehouses in Bronze. This works as expected. Within Silver, I then create Materialized Lake Views (MLVs) for my entities. For example, I create a Person entity based on multiple source tables and store the result in LH_Silver. This also works correctly. The issue occurs in the next step. On top of the Silver entity, I want to create dim_Person. The MLV reads the entity from LH_Silver, but the output should be written to LH_Gold in the Gold workspace. When OAP is disabled on all workspaces, this cross-workspace setup works and I can successfully write the MLV to Gold. However, as soon as OAP is enabled on the Silver workspace, I can no longer write the MLV to the Gold workspace. I've already tried several connection rules, including: FabricMaterializedLakeView FabricSqlEndpointMetadata Fabric SQL Analytics Endpoint Lakehouse Notebook Web V2 I've also configured an MPE for the Gold (3000) workspace, but so far none of these options have resolved the issue. Does anyone know which connection rule, MPE, or configuration is required to allow an MLV running from an OAP-enabled Silver workspace to write to a Lakehouse in another workspace? Ideally, I would like to keep the notebooks and MLV logic in the Silver layer rather than moving them to the Gold workspace. Thanks in advance! Cel 1: %%pyspark spark.conf.set("spark.sql.caseSensitive", "true") workspace = spark.conf.get("trident.workspace.name") environment = "DEV" if "DEV" in workspace else "TEST" if "TEST" in workspace else "PRD" spark.sql(f"SET TargetEnvironment = 3000_CURATED ({environment})") Cel 2: CREATE OR REPLACE MATERIALIZED LAKE VIEW `${TargetEnvironment}`.LH_3000.Algemeen.dim_Persoon AS SELECT * FROM test.`02_entity`.PersonFabric Welcome Popup - Hide/Disable
Team - I am back with another requirement from my end users. They dont want to see the "Welcome to Fabric View " pop-up when they log in using Fabric apps URL. I have gone through all the tenant setting and I dont see any way to hide or disable this pop-up. Did anyone come across similar requirement? Any thoughts or suggestions? -PattFabric IQ: Do Ontology entity synonyms work with Data Agent?
Hi, everyone! Short intro Currently I'm using the "super-duper-mega-nano-ultra" product - Microsoft Fabric to build natural language processing flow on-top of Microsoft Fabric Warehouse data. As for now It's rather a POC than production solution. I found a lot of the official Microsoft' documentation related to my task, but I have a little problem... The solution architecture (high-level) I made some investigations and as the result is the following architecture, which I want to implement (picture below): The idea is the next: the Microsoft Fabric Warehouse schema is connected to Microsoft Fabric Lakehouse, using shortcut; the Microsoft Fabric Ontology consumes the Microsoft Fabric Lakehouse as a data source for data binding; the Microsoft Fabric Data Agent uses a Microsoft Fabric Ontology (enriched with business context) to process natural language questions. The Microsoft Fabric Warehouse contains the following (dummy) objects (picture below): Tenant settings Microsoft documentation says, that specific tenant configurations should be applied to use Microsoft Fabric Ontology with Microsoft Fabric Data Agent (https://learn.microsoft.com/en-us/fabric/data-science/data-agent-tenant-settings) - everything is configured properly. Ontology configuration My Microsoft Fabric Ontology is configured as below (the configuration is influenced by Microsoft Fabric Ontology tutorial, which can be found here - https://learn.microsoft.com/en-us/fabric/iq/ontology/overview). Main view - two entities with a single relationship: ETLEntity entity configuration - the entity has the description, one synonym, metadata: ETLEntityRun entity configuration - the entity has the description, one synonym, metadata: As for now the Microsoft documentation says, that Microsoft Fabric Ontology descriptions, synonyms, metadata help Microsoft Fabric Data Agent to better understand the context (https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-add-semantic-enrichment). The problem My Microsoft Fabric Data Agent is connected to my Microsoft Fabric Ontology, which is described above, but the agent can't answer the simple questions about entities and the questions examples are provided below (the Microsoft Fabric Ontology Graph model was refreshed successfully before questions were asked): ETLEntity successful question without synonym usage: ETLEntityRun successful question without synonym usage: ETLEntity failed question with synonym usage: ETLEntityRun failed question with synonym usage: Looks like Microsoft Fabric Data Agent can't figure out, which entities are unicorn/wizard, even if they have appropriate synonyms. It's not my first iteration - I tried a lot, but result still the same every time. I feel like I missed something obvious in my configuration, but what... What are your thoughts? P.S.: the provided configuration is simple; objects and their metadata has no business context - It's just a sample, which I built to test some scenario; I think It's enough to check such use-case.
