Microsoft Fabric brings data movement, storage, analysis and reporting into one platform. The day-to-day experience still depends on how you organise the data, manage changes and support the people using it.
These Microsoft Fabric best practices focus on those choices, from selecting a data store to making sure a failed load does not quietly become an incorrect report.
1 Choose the right data storage
Start with the data, the processing it needs and the skills of the people supporting it. Fabric Warehouse is a useful fit for structured data and SQL-based reporting. Lakehouse suits work that combines files and tables with Spark-based processing. These are common fits, not exclusive rules; Microsoft’s data store decision guide explains the options.
A team already comfortable with SQL may find Warehouse easier to maintain than introducing notebooks for the same work. Choose what serves the task rather than trying to use every Fabric component.
2 Separate raw, cleaned and reporting-ready data
Keep incoming data separate from the data you have cleaned and prepared for reporting. In medallion architecture, these stages are usually called bronze, silver and gold. Each should have a purpose: preserve what arrived, resolve quality issues, then shape the data for use.
This makes problems easier to trace. If a currency conversion is wrong, you can find where it happened and rebuild the affected results. Our medallion architecture guide goes into the pattern in more detail.
Separate stages do not mean every team needs its own copy. OneLake shortcuts can reference data in supported locations without a separate ingestion copy. Reuse an approved product table where possible, with clear source ownership and access. A shortcut depends on its target, so it is not a backup; keep a separate copy when you need something like a historical snapshot.
3 Use shared models and consistent metrics
Prepare data for the questions people ask rather than exposing every source table unchanged. In Power BI, a star schema uses fact tables for events or measurements and dimension tables for products, customers and dates.
Be clear about each table’s grain. A sales table might contain one row per order line; mixing order totals into those rows can count the same amount more than once. Define shared calculations, such as net sales, in the semantic model so reports use the same definition. Check that relationships filter correctly and compare key totals with the source before sharing it.
4 Manage performance and capacity
A small reference table may be simplest to reload in full. A large table with a few daily changes is a better candidate for incremental loading. Fabric Copy job supports watermark-based copying and change data capture, depending on the source and connector.
Choose a method that captures the changes you need. An increasing order ID finds new orders but misses corrections to old ones. A reliable last-modified timestamp can capture those corrections, but not deleted rows by itself. Test inserts, updates, deletions and reruns, including whether the destination updates existing records or creates duplicates.
Pipelines, Spark jobs, queries and refreshes can share a Fabric capacity, so heavy concurrent processing can affect report responsiveness when capacity is under pressure. Where you see contention, stagger heavier jobs or refreshes where practical.
Use the Capacity Metrics app to find expensive operations and compare them with slow runs or reports. Look at sustained demand, delays and throttling, rather than one high utilisation reading. Remove avoidable processing, measure again and increase capacity when the remaining demand justifies it.
5 Monitor data quality and reliability
A successful pipeline run does not tell you whether the data is complete or correct. Check for missing IDs, duplicate records, unexpected values and missing source deliveries as you prepare it. Focus on errors that could change an answer, and decide what should happen when a check fails.
For example, order lines with missing product IDs should be flagged for review rather than silently disappearing from product totals. A missing day’s extract may justify holding back an updated report. Our data-cleaning guide covers checks you can adapt.
Give each important pipeline an owner, a working failure alert and short recovery instructions. Use pipeline monitoring to investigate errors, and test whether rerunning a failed load replaces, updates or duplicates records. Show the last successful data update to report users, so yesterday’s figures do not look current.
6 Test changes before production
Keep development separate from the production environment. Use test and production workspaces where needed, with Git integration and deployment pipelines for supported items. Before releasing a change, check its connections, destinations, refresh settings and a few known totals.
Deployment does not move everything. For example, lakehouse deployment moves supported metadata, not table and file data, so a new target lakehouse needs its data loaded. Check the deployment documentation for the items you use rather than assuming credentials, permissions and schedules carry across. Verify the production connections and results after release too.
7 Limit access and test permissions
Someone who needs a report should not automatically be able to change its pipelines or read all the underlying data. Use groups where practical and choose workspace roles, item permissions and data access to match what each person needs.
Test with the intended reader’s permissions, not only an administrator account. Check what they can see in the report and through any direct access to its data. Hiding a column in a report does not restrict access to it elsewhere.
Where to start
Start with the gap most likely to expose data, produce the wrong answer or interrupt important work. Fix it in one part of your setup, check the result and apply what you learn elsewhere.
If you want help reviewing your Fabric setup, talk to Salam about where it is becoming difficult to manage.
