Power BI semantic model development
One model. One number. Every report agrees.
You get a certified Power BI semantic model where revenue, margin, customer, and stock-keeping unit mean the same thing in every report on every team. Star-schema design, governed DAX library, row-level security, and full Tabular Editor source control from one Microsoft partner team.
0
semantic models in production
0 of 0
canonical "revenue" definition per tenant
0%
average report build time reduced after a certified model
ships
Why your numbers disagree
Reports lie when the model is wrong.
You do not have a Power BI problem. You have a semantic layer problem. Twelve PBIX files each build their own joins, their own DAX, and their own version of revenue. The chief financial officer opens three reports and gets three different numbers. The fix is not another dashboard. The fix is one certified model behind every report.
The problem · no semantic layer
- Every PBIX file is its own world.Twelve report authors, twelve copies of fact_sales, twelve definitions of "net revenue". Nobody is wrong. Nobody is the same.
- DAX measures live in nobody's source control.Critical logic lives inside an analyst's PBIX. Open it on a different machine and refresh fails. Change a column upstream and every report breaks silently.
- Star schema is missing entirely.Snowflakes, many-to-many relationships, and bidirectional filters everywhere. DirectQuery is unusable. Aggregations cannot be added. The model fights you.
- Row-level security is "we trust the workspace".Sales reps can see every region's pipeline. HR salary data sits in a workspace 47 people can browse. Audit will ask, and the answer will be embarrassing.
- A new report takes 3 weeks because there is no model to point at.Every request restarts with "where does the data live and which definition of margin do you want this time?" That is not analytics. That is rework.
The fix · certified semantic model
- One published, certified dataset behind every report.Every author connects live to the same model. Revenue is revenue. Margin is margin. The chief financial officer and the regional sales lead read the same number from the same source.
- DAX library in Tabular Editor with Git source control.Every measure has a folder, a description, and a pull request history. Calculation groups handle time intelligence. Best practice analyzer runs on every change.
- Strict star schema with conformed dimensions.Fact tables at the centre. Dimension tables for date, customer, product, region, employee. Single direction filters. DirectQuery, aggregations, and composite models become real options again.
- Row-level security enforced in the model itself.DAX roles tied to Microsoft Entra ID groups. Region managers see their region. HR data sees one person. Audit logs prove who saw what, on which day.
- New reports take hours, not weeks.Authors connect to the certified model and drag fields. The hard work is already done. A board ad-hoc question gets answered in the same meeting it was asked.
Inside a Redefine semantic model
Five layers that make one trusted model.
Click any tab to inspect the layer. The tour auto-advances every 4 seconds and loops. Click any item to jump to that layer.
1
Fact tables
fact_sales, fact_inventory, fact_gl. Grain documented.
Partitioned for incremental refresh.
2
Conformed dimensions
dim_date, dim_customer, dim_product, dim_region. Single
direction filters. Slowly changing dimension type 2 where
it matters.
3
DAX measure library
Tabular Editor. Folders. Descriptions. Calculation groups
for time intelligence. Best practice analyzer green.
4
Relationships and storage mode
Import for dimensions, DirectQuery on fact, aggregations
for speed. Composite model where it earns its keep.
5
Row-level security
DAX roles bound to Entra ID groups. Dynamic row-level
security for managers. Audit log on every viewer event.
Fact tables in this model
- fact_sales14.2M rows
- fact_inventory_snapshot38.1M rows
- fact_gl_ledger6.8M rows
- fact_ar_aging412k rows
fact_sales · partitioning
Grain
1 row per invoice line per day
Partition strategy
Monthly. Incremental refresh window 36 months.
Historical archive 60 months.
Last refresh
02:14 today · 3m 47s
Why this matters
Fact tables hold the events you measure. Their grain
decides what every report can answer. Get this wrong and
no amount of DAX rescues it.
dim_date
Conformed
12 attributes · calendar and fiscal
dim_customer
Slowly changing dimension type 2
147k rows · history preserved
dim_product
Slowly changing dimension type 1
8.4k stock-keeping units · category tree
dim_region
Conformed
Region to country to city
dim_employee
Slowly changing dimension type 2
Manager hierarchy · row-level security source
dim_account
Conformed
General ledger chart of accounts · ragged
Conformed means
"Customer" in fact_sales and "customer" in fact_ar_aging
point at the same dim_customer row. One filter slices
both. No more reconciliation meetings.
Measure folders
- 01. Revenue14
- 02. Margin9
- 03. Customer11
- 04. Inventory7
- Calculation group: Time Intelligence8
[Net Revenue]
Net Revenue :=
VAR _gross =
SUMX (
fact_sales,
fact_sales[qty] * fact_sales[unit_price]
)
VAR _credits =
CALCULATE (
SUM ( fact_sales[credit_value] ),
fact_sales[doc_type] = "CRM"
)
RETURN
_gross - _creditsBest practice analyzer greenFolder: 01. RevenueLast pull request number 418 · 2 days ago
Filter direction
Single, dimension to fact
Storage mode
Composite (DirectQuery on fact)
Aggregations
2 levels · 41x faster
Row-level security roles
- Regional ManagerDynamic
- Sales RepresentativeDynamic
- Finance Read-onlyStatic
- HR CompensationStatic
- External AuditorRead snapshot
Regional Manager · DAX role filter
[region_id] IN
CALCULATETABLE (
VALUES ( dim_employee[region_id] ),
dim_employee[email] = USERPRINCIPALNAME ()
)What you get in the build
Every deliverable.Nothing implied.
Fixed-fee scope per phase. Source code in your Git. PBIX, Business Intelligence Model, and runbook in your tenant on day one. We do the engineering; your team does the validation calls and final user acceptance testing.
Sample deliverable · model Business Intelligence Model in
Tabular Editor
Sample deliverable · star schema in Power BI Desktop
Phase 1 · deliverable
Star-schema model architecture
A documented model design before a single line of DAX. Grain decisions, conformed dimension list, slowly-changing-dimension policy per dimension, storage mode strategy, and the kill-list of legacy tables that do not enter the model.
Output
Model design document (PDF)
Sign-off
Chief financial officer and data owner
Standalone value
$8,400
Timeline
Week 1 to 2
Phase 2 · deliverable
Tabular model (Business Intelligence Model)
Built in Tabular Editor. Source-controlled in Git. Best practice analyzer green. Calculation groups for time intelligence. Standalone value $14,200.
Phase 3 · deliverable
Row-level security pack
DAX roles bound to Entra ID groups. Dynamic row-level security for hierarchies. Test-as-user harness. Audit log shipped to your tenant. Standalone value $6,800.
Phase 4 · deliverable
Certified DAX library
Every business measure named, folded, and documented. Calculation groups handle year-to-date, month-to-date, prior year, and rolling 12. Performance Analyzer baseline captured for every measure.
Measures
40 to 80 typical
Calculation groups
2 to 4
Standalone value
$12,400
Phase 5 · deliverable
Refresh and gateway runbook
Incremental refresh on fact, on-premises data gateway sized, refresh schedule documented, monitoring webhooks into Teams. Standalone value $4,600.
Phase 6 · deliverable
Handover and enablement
Two enablement workshops for your authors. Recorded walkthrough of every measure folder. 30-day post go-live support window. Standalone value $5,800.
Stack total
$52,200 of work
Delivered as a fixed-fee programme from $38,000 for a single-source model, or scoped line by line for multi-source warehouses.
Submit your brief › call within 48 hours › scoped proposal in 3 days › Sprint 1 begins within 1 week of sign-off
Get My Scoped QuoteProof · Parsons Kellogg semantic model
From 30 disconnected stores to $90M of unified reporting.
Parsons Kellogg, a promotional products and corporate apparel leader, operated 30 storefronts and over one million inventory items across fragmented backend systems. Manual processes and disconnected analytics held annual revenue at $14M. A unified Power BI semantic model on top of Dynamics 365 enterprise resource planning changed the operating model. Revenue scaled to $90M.
Client
Parsons Kellogg
Promotional products · corporate apparel · 30 stores
Problem
No unified visibility across 30 stores, 1M and more inventory
items, and multiple backend systems. Reporting fragmented.
Decisions slow. Warehouse workflows constrained.
Result
Real-time semantic model on Dynamics 365 enterprise resource
planning. Annual revenue scaled from $14M to over $90M.
Automation and unified analytics across the operation.
Week 1 · audit
Discovery across 30 stores, Dynamics 365 enterprise resource
planning, and 1M and more stock-keeping unit catalogue.
Mapped every report request, every legacy data source, every
duplicated definition of "revenue" and "stock on hand".
Killed 41 redundant reports before any build started.
Week 3 · model design
Conformed dimensions agreed across all 30 storefronts.
One dim_customer, one dim_product, one dim_store. Slowly
changing dimension type 2 on customer. Single, certified
definition of net revenue signed off by finance.
Week 6 · build
Tabular model and DAX library live in production.
Built in Tabular Editor with Git source control. 64
certified measures across revenue, margin, inventory, and
operations. Calculation groups for time intelligence.
Representational State Transfer application programming
interface surface published for mobile applications.
Week 9 · security
Row-level security live across all 30 storefronts.
Store managers see their store. Regional vice presidents see
their cluster. Audit log wired to the Power BI admin tenant.
Compliance signed it off in one session.
Month 4 · handover
Internal authors building new reports in hours, not weeks.
Two enablement workshops with internal analysts. Within 60
days the in-house team had shipped 23 new reports off the
certified model. Build velocity 7x.
Outcome · 24 months on
$14M to $90M annual revenue, one model behind every report.
Unified inventory and order visibility across 30 stores.
Real-time financial reporting to the leadership team. The
platform now supports continued growth without rework.
0M
starting annual revenue
0M+
annual revenue post-build
0
storefronts on one model
0
certified DAX measures
Before model
3 weeks
average time to ship a new executive report
After model
0 hrs
average time to ship a new executive report
Definition drift
0
conflicting definitions of revenue removed from the estate
Report rebuilds
0%
faster average rebuild time across the analyst team
The cost of staying put
A model pays for itself in analyst hours saved.
Three analysts at $95k each, spending 60% of their week reconciling reports and rebuilding the same logic, is $171k a year of pure rework. A certified semantic model lands between $38k and $78k as a one-time fixed fee. The build pays back inside the first quarter, every time.
And that is before you count the cost of bad decisions made on numbers that did not match. We have never seen that line item land below six figures.
Get My Return On Investment EstimateWhy Redefine for semantic model work
Three things other partners will not commit to.
Claim 01
Your tenant. Your Git. Your DAX. Day one.
Every model artifact lands in your Microsoft tenant, your Azure DevOps or GitHub, and your Power BI workspace from the first commit. No partner-owned PBIX files. No "you can have the Business Intelligence Model when the contract ends". You can sack us in week 4 and the model keeps running.
PBIX and Business Intelligence Model in your
repositoryDAX library in source controlRefresh history in your tenantNo proprietary tooling
Claim 02
Best Practice Analyzer must pass before we invoice.
Every measure, every relationship, every storage mode choice runs through Tabular Editor's Best Practice Analyzer and passes before the final invoice goes out. Other partners ship a model that works on the surface and fails the audit six months later. We do not.
Best Practice Analyzer green report attached to
sign-offPerformance Analyzer baselineDAX Studio capture historyVertiPaq sizing report
Claim 03
Your team writes the next 50 measures, not us.
A semantic model is only useful if your analysts can extend it. Two enablement workshops, a recorded walkthrough of every measure folder, and a 30-day post go-live window where we sit alongside your authors are baked into every build. The opposite of vendor lock-in.
2 enablement workshopsRecorded measure walkthrough30-day support windowNo retainer required to extend
Sibling Power BI services
Need a sibling build?
A semantic model is one phase of a Power BI engagement. The rail auto-scrolls through related services. Hover to pause and open any card before your discovery call.
Hub
Power BI services
Strategy, builds, integrations, managed support across the
full service tree.
Adjacent
Power BI consulting
Strategy and architecture work before the build kicks off.
Adjacent
Power BI implementation
End-to-end implementation programmes for mid-market and
enterprise.
Adjacent
Power BI development
Reports and dashboards built on top of your certified model.
Sibling
Dashboard development
Executive dashboards designed for daily use, not pretty
screenshots.
Sibling
Report development
Operational and finance reports off a single certified
semantic model.
Proof
Power BI audit
Audit your existing model before you commit to a rebuild.
Support
Managed Power BI
Day-after-go-live support, refresh monitoring, model
evolution.
Integration
Dynamics 365 integration
Wire Dynamics 365 enterprise resource planning and customer
relationship management into the model the right way.
Power BI semantic model frequently asked questions
The questions chief financial officers ask first.
A semantic model is the published Power BI dataset that holds your tables, relationships, and business measures. It is the single layer between raw data and every report your team builds. Without it, every report author rebuilds the same logic differently, and every executive report tells a slightly different story. Invest in the model and every downstream report becomes faster, cheaper, and consistent.
A single-source model, for example Dynamics 365 Business Central or Finance and Operations alone, ships in 4 to 6 weeks. A multi-source model spanning enterprise resource planning, customer relationship management, and finance applications is typically 8 to 12 weeks. We scope it line by line in the first 5 business days and quote a fixed fee.
No. Existing PBIX files are re-pointed to the new published model using "Live connection". The visuals and layout you already have are preserved. The only thing that changes is where the data and measures come from. We rebuild the broken ones; you keep the good ones.
Yes. Every measure has a folder, a plain-English description, and a documented use case. Two enablement workshops walk your analysts through the library. The model lives in Git, so every change has a pull request history. Most clients are extending the model independently within 60 days.
A single-source semantic model with up to 40 measures starts at $38,000 fixed-fee. A multi-source model with row-level security, 60 or more measures, and aggregations lands between $58,000 and $84,000. We quote line by line after the discovery call so the price reflects your actual data estate, not an average.
Row-level security roles are defined in the model using DAX expressions bound to Microsoft Entra ID security groups. For hierarchical access, dynamic row-level security uses USERPRINCIPALNAME to filter by employee, region, or business unit. Every role is tested using "Test as user" in Power BI Service and the test results are signed off by your security or audit lead before go-live.
Yes. About a third of our semantic model engagements start as a rescue. We run a Best Practice Analyzer audit first, classify every measure and relationship as keep, refactor, or rebuild, and quote a remediation plan. In some cases we save more than we rebuild. No judgement about how it got there.
Are you ready for a semantic model
Three questions. Real answer at the end.
Click the option that matches your situation. We will read it back honestly. No email required.
Question 1 of 3
How many definitions of "revenue" exist across your team's
reports today?
Question 2 of 3
If your lead Power BI analyst left tomorrow, what happens to the
DAX library?
Question 3 of 3
How long does a new executive report take from request to live
in Power BI?
Not sure? Tell us your situation and we will be straight with you.
Book a model scoping call
Submit your brief. Get a scoped model plan in 5 days.
Tell us about your reporting estate, your data sources, and what is failing. We will book a 45-minute discovery within 48 hours, send a line-by-line scoped model plan within 5 business days, and have your first certified semantic model live within 6 weeks of sign-off.
48-hour response
discovery call within 2 business days
5-day scoped plan
grain, dimensions, fee, line by line
120+ models live
mid-market and enterprise reporting
Your tenant
PBIX, Business Intelligence Model, DAX, runbook stay with
you
Discovery call within 48 hours · scoped plan in 5 days · first certified semantic model live within 6 weeks of sign-off
Brief received. We will review your reporting estate and send a
scoped semantic model plan within 5 business days.