From Salesforce to Power BI: A T-SQL Modelling Route That Holds Up

Walk the full stack - incremental extract into raw tables, staging rules, star schema, usp_ orchestration, and a thin semantic layer. Synthetic examples, operator-grade patterns.

The native Salesforce connector is fine until volume and grain force a SQL warehouse. Most CRM-to-BI projects fail in the handoff: Salesforce semantics land in SQL unchanged, stored procedures become a black box, and Power BI inherits every grain mistake as a DAX hack.

This interactive walkthrough follows one route we use with teams who already live in T-SQL and Power BI:

Salesforce - objects, soft deletes, incrementals on SystemModstamp
T-SQL extract - raw.sf_* landing zone with watermarks and MERGE
Staging - typed views, dedupe, delete flags carried forward
Star schema - dims, facts, explicit grain, SCD2 where names change
usp_ procedures - nightly orchestration, logging, idempotent layers
Power BI - relationships and measures on a model that does the work

Use the pipeline control below to inspect code, table shapes, and notes at each stage. Everything is synthetic - the patterns are what we ship.

Click each stage to walk the pipeline - then scroll to the report preview to see how KPIs change from a bad export to a trusted Power BI model.

Pipeline

Stage 1 of 6

Source: Salesforce objects and API quirks

Define which CRM entities feed the warehouse and how Salesforce semantics differ from relational rows.

Why it matters

Reports break when you treat Salesforce like a normal SQL source - deletes are soft, timestamps drive incrementals, and compound fields do not land as scalar columns.

Common pitfalls

Full reloads that ignore IsDeleted and resurrect churned accounts in Power BI.
Using CreatedDate instead of SystemModstamp for incremental pulls - you miss updates.
Formula fields that change without row updates - incrementals miss them unless you schedule periodic full refreshes.
Flattening Account.Name into facts without a stable Account key.

{
  "Id": "001xx000003DGbQAA0",
  "Name": "Northwind Labs",
  "Industry": "Software",
  "AnnualRevenue": 2400000.0,
  "OwnerId": "005xx000001Sv2AAAS",
  "IsDeleted": false,
  "SystemModstamp": "2026-09-28T14:22:01.000+0000",
  "BillingStreet": "100 Market St",
  "BillingCity": "San Francisco",
  "BillingState": "CA",
  "BillingPostalCode": "94105",
  "BillingCountry": "United States",
  "Customer_Tier__c": "Enterprise"
}

What the report shows at this stage

Sales Pipeline

Unreliable

Live export view

Open pipeline

$12.6M

Win rate

44.0%

Pipeline coverage

n/a

Open pipeline by stage

Weekly pipeline snapshot

No history yet

Snapshot fact fills after usp_refresh_pipeline_snapshot runs.

Includes 142 soft-deleted accounts still in the export.
Win rate uses closed-won over all rows, not closed opportunities only.

Source: Salesforce objects and API quirks

Define which CRM entities feed the warehouse and how Salesforce semantics differ from relational rows.

Why it matters

Reports break when you treat Salesforce like a normal SQL source - deletes are soft, timestamps drive incrementals, and compound fields do not land as scalar columns.

Common pitfalls

Full reloads that ignore IsDeleted and resurrect churned accounts in Power BI.
Using CreatedDate instead of SystemModstamp for incremental pulls - you miss updates.
Formula fields that change without row updates - incrementals miss them unless you schedule periodic full refreshes.
Flattening Account.Name into facts without a stable Account key.

{ "Id": "001xx000003DGbQAA0", "Name": "Northwind Labs", "Industry": "Software", "AnnualRevenue": 2400000.0, "OwnerId": "005xx000001Sv2AAAS", "IsDeleted": false, "SystemModstamp": "2026-09-28T14:22:01.000+0000", "BillingStreet": "100 Market St", "BillingCity": "San Francisco", "BillingState": "CA", "BillingPostalCode": "94105", "BillingCountry": "United States", "Customer_Tier__c": "Enterprise" }