Technology / Power BI
Better reporting starts below the visual.
Power BI is Microsoft's business intelligence platform for building semantic models and dashboards on top of governed data. Quorlytic designs the fact grain and measure definitions before the visuals, tests row-level access with real user identities rather than assuming a hidden report page is secure, and gives every model a named owner after handover.
By QuorlyticUpdated
Build reporting around a trustworthy model. Power BI can support a governed decision layer when metrics, relationships, security and refresh behavior are designed together.
Architecture role
Where Power BI fits.
Power BI commonly sits at the consumption end of the architecture, translating governed data into a semantic model that people and applications query. The architecture decision is the model grain, the metric definitions and the access boundary behind every report.
Position in the end-to-end path
- 01Business sourcesSystems and warehouses
- 02Governed dataModelled and validated data
- 03Power BISemantic model and reporting
- 04Decision viewsMeasures, dashboards and access
- 05Business actionWorkflow and accountability
Sources
- ERP
- CRM
- Finance
- Files
- Web
- Ops
Certified metrics
- Revenue
- Margin
- Churn
Reports
- Executive
- Operational
- Self-service
Illustrative architecture. It shows a typical position for discussion, not a mandatory stack or a client implementation.
Fit and capability
When it is relevant, and what the work involves.
Relevant workloads
- Semantic models
- Executive reporting
- Self-service
- Governed measures
Engineering capabilities
- Fact grain and relationship review
- Metric dictionary and validated measures
- Role-based access and refresh test plan
- Report ownership and adoption walkthrough
Integration points
What it connects to.
The platform is only as useful as the boundaries around it. These are the interfaces that usually need an explicit decision.
- 01Warehouse / data platform
- 02Identity and access
- 03Data refresh gateways
- 04Workspace governance
Delivery and operating considerations
What to decide before you commit.
Each consideration changes something concrete in the architecture, the operating model or the cost profile.
- 01
Choose the correct grain
Describe what one row represents in every fact table. Separate transactions, snapshots and targets where their grains differ. Microsoft recommends star-schema principles for semantic-model performance and usability; validate the design against actual report questions.
- 02
Control measure definitions
Centralize reusable calculations and document the effect of filters, time periods, currency and returns. Compare measures to approved samples. A single semantic model still needs a named business owner who can resolve competing definitions.
- 03
Test access as different users
Design workspace responsibilities and row-level access around the deployment context. Validate behavior using the identities and roles that will consume reports. Do not assume hiding a visual or a report page secures underlying data.
- 04
Plan refresh and adoption
Map refresh dependencies, required gateways, failure alerts and licensing choices. Make refresh state visible to report users. Roll out around a specific decision workflow and record who maintains the model after handover.
- 05
Understand where the platform is heading
Microsoft’s analytics stack now spans Power BI, Fabric and Azure data services, which changes where storage, transformation and the semantic model live. A team choosing a target architecture should know which parts of it are being consolidated, what the licensing consequences are, and which decisions can wait. Migrating a working reporting estate without a stated trigger usually costs more than it returns.
- Target architecture stated before consolidation begins
- Licence and capacity impact estimated per user group
- Existing reports mapped to the target model grain
Typical delivery sequence
- 01Business sources
- 02Semantic model
- 03Access & refresh
- 04Decision views
Decision table
When Power BI fits, and when to compare.
| Dimension | Power BI is a strong fit | Compare alternatives when |
|---|---|---|
| Estate | The organisation runs on Microsoft 365, Azure or Fabric. | Most report consumers work outside Microsoft tooling. |
| Modelling | A shared semantic model with certified datasets and DAX measures serves most reports. | Metric definitions must live upstream in a code-defined semantic layer that several tools share. |
| Audience | A broad self-service audience publishing reports for colleagues. | A small analyst group doing exploratory visual analysis across mixed sources. |
| Licensing | Per-user or capacity licensing matches the viewer mix. | Large models and frequent refresh would force capacity sized for peaks that rarely occur. |
| Freshness | Import or Direct Lake refresh windows meet the decision's needs. | Every view needs near-real-time data from a source that DirectQuery would overload. |
Questions
Questions worth asking.
Can we improve existing reports?
Yes. A bounded model review can identify inconsistent calculations, problematic relationships and refresh dependencies before redesigning visuals or moving the entire reporting estate.
Can we optimise Power BI cost?
Capacity is usually the dominant cost, and it tracks model size, refresh volume and query concurrency rather than user count alone. Reduce model size and refresh pressure first, then size capacity against measured demand. Premium per-user options only make sense for a subset of consumers.
Integration ecosystem
What sits around Power BI.
Adjacent technologies grouped by the role they play next to this platform, and why that role usually needs an explicit decision.
Data platform
- Snowflake
- Databricks
- Synapse
- Fabric
- SQL Server
Where the curated tables live. Refresh behaviour and query pushdown depend on this more than on report design.
Modelling
- Semantic models
- DAX
- Power Query
- Calculation groups
The measures, relationships and hierarchies the business agreed to. This is the product; the reports are downstream of it.
Identity and access
- Entra ID
- Row-level security
- Object-level security
- Workspace roles
Access has to be enforced in the model and tested with real role identities, not demonstrated from an administrator account.
Delivery
- Workspaces
- Apps
- Deployment pipelines
- Embedded
How a report reaches its audience, and how a change is promoted through environments without breaking it.
Operations
- Gateways
- Refresh schedules
- Capacity metrics
- Usage analytics
Refresh and capacity are where Power BI performance problems usually originate, and usage analytics is how unread reports get retired.
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Migration and modernization
What moves, and what that asks of you.
Common transitions. Most Power BI work is a consolidation rather than a greenfield build.
Spreadsheet reportingGoverned semantic model
The definitions are the migration. Recreating the spreadsheet as a dashboard without resolving the calculation reproduces the problem in nicer typography.
Import models on extractsDirectQuery or composite models
Worth considering when data volume or freshness outgrows a scheduled import. It moves the performance problem into the platform, so query performance has to be addressed there.
Many independent reportsCertified shared datasets
The consolidation that ends competing versions of a measure. It is a governance change first and a technical change second.
Another BI toolPower BI
Usually driven by Microsoft licensing alignment. The semantic model has to be rebuilt rather than converted, so it is the moment to fix definitions rather than port them.
Performance and economics
What drives the bill.
Cost sits in licensing and capacity rather than in query volume, which makes the decisions different in kind from a warehouse.
- Licensing model
- Per-user and capacity-based licensing suit different audience shapes, and the crossover depends on how many people consume rather than build.
- Capacity
- Refresh and query load share capacity, so a heavy overnight refresh can degrade interactive performance for everyone on it.
- Refresh frequency
- A dashboard refreshing far more often than anyone reads it is a direct and common cost, and the fix is a conversation with the consumer.
- Model size
- Import model size drives memory and refresh duration; aggregations and composite models are the usual levers.
- Downstream platform cost
- DirectQuery moves cost onto the data platform. The saving in Power BI can be more than offset there if the platform is not ready.
Governance and security
What has to be designed first.
What keeps a semantic model trustworthy once more than one team publishes.
- Certification
- Certified and promoted datasets with a named owner, so a consumer can tell which dataset is authoritative.
- Row-level security
- Defined in the model and tested with the identities real consumers hold, including the composite and embedded cases.
- Publishing boundary
- Who may publish to which audience, and what happens to an uncertified report that contradicts a certified one.
- Change control
- Model changes reviewed and promoted through deployment pipelines, because a silent measure change is a silent restatement.
- Lifecycle
- Usage analytics used to retire unread reports, so the workspace stays navigable and refresh cost stays proportionate.
Trade-offs
When it fits, and when it does not.
Where Power BI fits, and where another consumption tool or a different layer deserves consideration.
Where Power BI tends to fit
- Organisations already standardised on Microsoft identity and licensing
- A large self-service audience that needs a governed model rather than open query access
- Reporting where row-level security must be enforced consistently across many reports
- Estates consolidating competing measure definitions into certified datasets
Where another answer deserves consideration
- TableauThe primary need is exploratory visual analysis across mixed sources rather than governed reporting at scale.
- LookerThe team wants modelling expressed in code and version-controlled, with governed reuse enforced by the modelling layer.
- A warehouse-side semantic layerSeveral consumption tools must share one definition. Holding measures only in Power BI means anything not using Power BI re-derives them.
- Fixing the data firstDashboards disagree because the underlying models disagree. No BI tool resolves an upstream modelling problem.
References
Primary sources for this platform.
Vendor documentation, linked for verification. It is not an endorsement, partnership or certification.
Next step
Discuss your Power BI semantic model.
Bring one disputed measure. The model design conversation usually starts there rather than with licensing.