Can a Non‑IT Professional Learn Microsoft Fabric? A Realistic 90‑Day Roadmap

The Starting Point: A Real HR/Finance Scenario

Emma’s HR team has:

• Payroll data in monthly Excel files
• Headcount and org data in a SaaS HR system with an OData API
• Learning and development data exported from a separate platform
• A Power BI report that refreshes slowly and breaks whenever file names change

Pain points:

• No single, trusted view of headcount by cost center and manager
• Manual VLOOKUP‑style reconciliation every month
• HR leadership asking for near‑real‑time views, but IT is busy with other priorities

Emma’s goal for 90 days:

Build and own a Fabric solution that lands HR data in OneLake, refreshes daily, and powers a stable Power BI report for headcount and attrition.

She’s allowed to use Fabric and Power BI, but not to rely on IT for day‑to‑day changes.

Week 1–2: Grounding in Fabric, Without Drowning in Architecture

Emma already knows Power BI and basic data modeling. She doesn’t need a full platform deep‑dive, but she does need to understand what she’s touching.

Key Fabric concepts she must be clear on

• OneLake: The unified storage layer backing Fabric items. For Emma, the important part is that Lakehouses, Warehouses, and Dataflows Gen2 land data in OneLake in an open format (Delta tables for Lakehouses).
• Workspaces: Security and deployment boundary. Fabric items live inside a workspace; permissions are managed per workspace.
• Lakehouse vs Warehouse:
  • Lakehouse: Uses Delta tables, good for file‑based and semi‑structured data, accessible via SQL analytics endpoint and Apache Spark.
  • Warehouse: Relational engine with T‑SQL surface, optimized for structured data and BI‑style queries.
• Dataflows Gen2: Power Query‑based ETL in Fabric that can land data into Lakehouses or Warehouses.

Emma’s Week 1–2 checklist

1. Create a dedicated Fabric workspace for HR analytics

   • Set her HR leadership group as Viewer or Contributor depending on governance.
   • Ensure she has at least Member permissions to create items.

2. Spin up a simple Lakehouse

   • Create a Lakehouse named HR_Analytics_Lakehouse.
   • Note that Fabric automatically creates a SQL analytics endpoint for the Lakehouse; she’ll use it later for Power BI.

3. Confirm basic security behaviour

   • Understand that workspace permissions control access to Lakehouse tables and SQL analytics endpoints.
   • Row‑level security for reports is implemented in Power BI, not directly in Lakehouse tables.

By the end of week 2, Emma isn’t an architect, but she knows:

• Where her data will live (OneLake via Lakehouse)
• How people will access it (Power BI via Lakehouse SQL analytics endpoint)
• Who can see what (workspace roles + Power BI RLS later)

Week 3–4: Landing HR Data into OneLake with Dataflows Gen2

The first big win is to stop relying on manually managed Excel files. Emma’s focus: get three core datasets into OneLake daily.

Target datasets

• Employees (from HR SaaS via OData)
• Payroll (from Excel files in SharePoint or OneDrive)
• LearningEvents (from CSV exports)

Using Dataflows Gen2 for ingestion

Emma chooses Dataflows Gen2 because:

• She already knows Power Query from Power BI.
• Dataflows Gen2 can directly write to Lakehouse tables.

Step 1: Create a Dataflow Gen2 for Employees

1. In the HR workspace, create a Dataflow Gen2.
2. Use the OData feed connector to the HR SaaS API.
3. In Power Query, apply transformations:
   • Filter to active employees
   • Normalize department and cost center codes

Example Power Query step to standardize department codes:

let
    Source = OData.Feed("https://hr-saas.example.com/odata/employees", null, [Implementation="2.0"]),
    Employees = Source{[Name="Employees"]}[Data],
    FilterActive = Table.SelectRows(Employees, each [Status] = "Active"),
    TrimDept = Table.TransformColumns(FilterActive, {{"DepartmentCode", Text.Trim, type text}})
in
    TrimDept

4. In the destination settings, Emma maps the output to a new Lakehouse table:

   • Destination: Lakehouse
   • Lakehouse: HR_Analytics_Lakehouse
   • Table name: Employees

5. Set the refresh schedule to run daily (e.g., early morning) using the dataflow’s built‑in scheduling.

Step 2: Create a Dataflow Gen2 for Payroll files

1. Use the SharePoint Folder connector pointing to the payroll library that stores monthly Excel files.
2. Combine files in Power Query, making sure the schema is consistent.
3. Map the output to a Lakehouse table Payroll.

Key detail: Emma keeps the transformations schema‑stable (same column names and types) so new monthly files append cleanly. She avoids using file‑specific transforms that would break when a new file appears.

Step 3: Create a Dataflow Gen2 for Learning data

1. Use the File or SharePoint Folder connector for CSV exports.
2. Clean up date formats and user IDs.
3. Map to a Lakehouse table LearningEvents.

By end of week 4, Emma has:

• Three Lakehouse tables refreshed daily
• No manual copy‑paste of HR data
• A clear separation between ingestion (Dataflows Gen2) and consumption (Power BI later)

Week 5–6: Structuring the Lakehouse for Reporting

Right now, Emma’s Lakehouse has raw‑ish tables. They’re usable, but not ideal for reporting. She needs a simple, understandable structure.

Choosing between Lakehouse and Warehouse for modeling

For Emma’s scope:

• Lakehouse is already in use and supports Delta tables.
• The Lakehouse SQL analytics endpoint gives her a relational view suitable for Power BI.

She decides to keep everything in the Lakehouse and use the SQL analytics endpoint for her semantic model. A dedicated Warehouse could make sense later for broader reporting, but it’s not required for this 90‑day goal.

Creating curated tables via Lakehouse SQL analytics endpoint

Emma uses the Lakehouse SQL analytics endpoint to define curated tables or views that Power BI will consume.

Example: Create a FactPayroll table joining Employees and Payroll.

CREATE TABLE dbo.FactPayroll
AS
SELECT
    p.PayrollDate,
    p.EmployeeId,
    e.DepartmentCode,
    e.CostCenter,
    e.ManagerId,
    p.BaseSalary,
    p.BonusAmount,
    p.Currency
FROM
    dbo.Payroll AS p
INNER JOIN
    dbo.Employees AS e
    ON p.EmployeeId = e.EmployeeId;

Notes:

• The Lakehouse SQL analytics endpoint supports T‑SQL for table creation and querying; Emma uses CREATE TABLE AS SELECT to materialize a curated fact table.
• When underlying raw tables refresh, the curated table does not automatically recompute. Emma schedules a process to rebuild FactPayroll after ingestion (either via a Notebook, stored procedure‑style pattern using SQL, or by using Dataflows Gen2 to create curated tables if she wants automatic refresh).

To keep things manageable in 90 days, Emma chooses a simpler pattern:

• Use Dataflows Gen2 for both raw and curated tables where possible.
• Use the SQL analytics endpoint mainly for ad‑hoc analysis and validation.

Example curated table via Dataflow Gen2

She creates a second Dataflow Gen2 called HR_Curated:

• Source: Lakehouse tables Employees and Payroll via the Lakehouse connector.
• Join them in Power Query.
• Output: Lakehouse table FactPayroll.

This way, when raw tables refresh, the curated dataflow can also refresh on a schedule, keeping the curated table in sync without custom orchestration.

By end of week 6, Emma has:

• Clear raw tables: Employees, Payroll, LearningEvents
• Curated tables: FactPayroll, plus a simple DimEmployee table if needed
• A repeatable pattern: raw ingestion dataflows → curated dataflows → Power BI

Week 7–8: Building the Power BI Model on Fabric

Now Emma connects Power BI directly to Fabric.

Connecting to the Lakehouse SQL analytics endpoint

In Power BI Desktop:

1. Choose Get data → SQL Server.
2. Use the Lakehouse SQL analytics endpoint connection string from the Fabric workspace.
3. Import tables FactPayroll and DimEmployee.

Important behaviours:

• The Lakehouse SQL analytics endpoint exposes tables in a relational way; Power BI can import them similarly to a Warehouse.
• For this scenario, Emma uses Import mode for predictable performance, given her HR datasets are moderate in size.

Building a semantic model

Emma defines relationships:

• DimEmployee[EmployeeId] → FactPayroll[EmployeeId]

She adds measures for headcount and salary.

Example DAX measures:

Headcount := DISTINCTCOUNT(DimEmployee[EmployeeId])

Total Base Salary := SUM(FactPayroll[BaseSalary])

Average Base Salary := 
DIVIDE(
    [Total Base Salary],
    [Headcount]
)

She then builds visuals:

• Headcount by department and manager
• Total and average salary by cost center

Publishing back to Fabric

Emma publishes the report to the same HR workspace. Key points:

• The dataset (semantic model) lives in Fabric and can be scheduled to refresh.
• The dataset refresh should be aligned with the Lakehouse dataflows refresh windows.

By end of week 8, Emma has:

• A Fabric‑hosted Power BI report
• A semantic model built on curated Lakehouse tables

The weekly headcount meeting now uses the Fabric report rather than ad‑hoc Excel extracts.

Week 9–10: Governance, RLS, and Making IT Comfortable

At this point, Emma’s solution is useful, but HR data is sensitive. She needs to tighten access.

Workspace‑level access

Emma works with IT or the Power BI admin to confirm:

• HR workspace is restricted to HR and selected finance stakeholders.
• External sharing is controlled via tenant settings.

Workspace roles:

• Viewer: Can see reports and datasets but cannot change them.
• Contributor: Can edit reports and create new ones.

Emma keeps most stakeholders as Viewer to avoid accidental changes.

Row‑level security in Power BI

Emma wants managers to see only their own teams. She implements RLS in the Power BI semantic model.

1. Create a role ManagerRole.
2. Use a DAX filter on DimEmployee based on the logged‑in user’s email.

Example RLS filter expression on DimEmployee:

[ManagerEmail] = USERPRINCIPALNAME()

Behaviour details:

• USERPRINCIPALNAME() returns the user’s UPN (usually email) in the Power BI service.
• The role must be assigned to users or groups in the Power BI dataset security settings.
• RLS applies when users view reports in the service; workspace admins and users with Build permission can bypass RLS depending on settings and roles.

Emma tests the RLS with a few manager accounts to confirm they only see their direct reports.

By end of week 10, Emma’s HR solution:

• Respects access boundaries via workspace roles
• Applies RLS to restrict views by manager

IT is more comfortable because governance is explicit, not ad‑hoc.

Week 11–12: Operationalising and Extending Beyond HR

The last two weeks are about making the solution operational, not a fragile prototype.

Aligning refresh and monitoring

Emma sets up:

• Dataflows Gen2 refresh schedules for raw and curated tables
• Dataset refresh schedule in Power BI

She makes sure:

• Dataflows run first (e.g., early morning).
• Dataset refresh happens after dataflows complete.

For monitoring:

• She reviews refresh history in the Fabric workspace.
• She configures failure notifications via Power BI dataset settings so she gets an email if refresh fails.

Handling schema changes

Real HR systems change. New columns appear; payroll formats evolve. Emma establishes a simple rule:

• Any schema change in source systems must be communicated to her before deployment.
• She updates Dataflows Gen2 transformations to handle new columns without breaking existing ones.

Practically:

• She avoids using Remove Other Columns in Power Query unless necessary, to reduce breakage risk.
• She tests changes in a separate workspace or a test dataflow before applying to production.

Extending to finance or other domains

By now, Emma’s pattern is reusable:

1. Land source data into a Lakehouse via Dataflows Gen2.
2. Create curated tables via additional dataflows.
3. Build Power BI models and reports on the Lakehouse SQL analytics endpoint.
4. Govern access via workspace roles and RLS.

A finance colleague can mirror the pattern for budgets and forecasts without needing to learn Spark notebooks or advanced engineering tools on day one.

What This 90‑Day Roadmap Proves

Emma is not an engineer. She never wrote Spark code, managed capacities, or built complex pipelines. But in 12 weeks, she:

• Stopped manual HR data reconciliation
• Landed key datasets into OneLake via Dataflows Gen2
• Built curated tables and a Power BI model on the Lakehouse SQL analytics endpoint
• Implemented RLS so managers see only their own teams

The concrete takeaway: if you already understand your business processes and basic Power BI, you can own a small Fabric solution in about 90 days by focusing on Dataflows Gen2, Lakehouses, and semantic models, and leaving advanced engineering features for later. Start with one messy process, give it a Lakehouse home, and make that your first Fabric win.