If you work with Microsoft Power BI, you've almost certainly heard this question over the past year:

"Do we still use Power BI, or are we supposed to move to Microsoft Fabric now?"

The short answer is straightforward: Power BI didn't go away. Fabric didn't replace it. But the context Power BI operates in has changed — and that matters for architecture, governance, and capacity planning.

This article breaks down what actually changed, what's mostly marketing, and how Power BI professionals should think about Fabric in practice today.

Power BI vs Fabric: The Correct Mental Model

Before Fabric, Microsoft analytics was a collection of loosely connected services:

• Power BI
• Azure Data Factory
• Synapse
• Dataflows
• Separate storage layers

Fabric's goal is consolidation:

• One platform
• One storage layer
• One capacity model

Power BI is now one workload inside Fabric, not a separate product line.

What Actually Changed (And Matters)

1. OneLake Is Real — and It's the Biggest Shift

Fabric introduces OneLake, a single, tenant-wide data lake shared across Fabric workloads.

Why this matters in practice:

• Data no longer has to be copied between tools
• Multiple teams can access the same underlying data
• Storage and compute are more clearly separated

Best-practice implications for Power BI:

• Treat OneLake as a centralized data foundation, not a dumping ground
• Keep transformation ownership clear (engineering vs BI)
• Use Power BI semantic models to consume and shape data, not to store it redundantly

This reinforces a long-standing Power BI principle: centralize data, standardize logic, decentralize reporting.

2. Dataflows Didn't Disappear — They Evolved (Carefully)

Power BI Dataflows still exist. Fabric adds Dataflows Gen2, which:

• Write directly to OneLake
• Can be reused by non–Power BI workloads
• Still use Power Query under the hood

What didn't change:

• They're best suited for light to moderate transformations
• They're not a replacement for full-scale data engineering pipelines
• They require careful performance and dependency management

Practical guidance:

• Use Dataflows for reusable, business-owned transformations
• Avoid pushing heavy joins, large-scale fact processing, or complex orchestration into them
• Keep Gen1 dataflows if they're stable and meeting business needs

3. Capacity: Unified, but Less Forgiving

Fabric introduces unified capacity (F-SKUs) that power:

• Power BI
• Data Engineering
• Data Warehousing
• Real-Time Analytics

This replaces multiple disconnected pricing and capacity models.

What's better:

• One shared pool of compute
• Easier architectural alignment across teams
• Fewer platform silos

What's harder in reality:

• Power BI Pro licenses are still required for authors
• BI workloads now compete with engineering workloads
• Poorly designed pipelines can directly impact report performance
• Cost attribution across workloads is still evolving

When Fabric Capacity Makes Sense (And When It Doesn't)

Fabric capacity is a strong fit when:

• Multiple teams share the same data platform
• BI, engineering, and analytics workloads coexist
• You already struggle with Premium constraints
• Centralized governance is a priority

Traditional Power BI Premium still makes sense when:

• Power BI is the primary or only workload
• Fabric engineering features are out of scope
• Cost predictability matters more than flexibility
• The BI team owns most of the data lifecycle

Fabric is not mandatory — it's optional architecture.

What's Mostly Hype (For Now)

"You Must Move Everything to Fabric"

Not true.

• Existing Power BI workspaces continue to work
• Premium capacities still exist
• Microsoft supports gradual, selective adoption

There is no requirement to redesign a functioning Power BI estate just because Fabric exists.

"Power BI Is Just a Front-End Now"

Also not true.

Power BI semantic models still:

• Define business metrics
• Enforce governance and security
• Control performance at query time

Fabric adds upstream options — it does not replace the semantic layer. Business logic still belongs closest to consumption.

Fabric Readiness: An Honest Reality Check

Fabric is directionally strong, but not frictionless:

• Monitoring across workloads is still fragmented
• CI/CD for Fabric assets is evolving
• Cost visibility at workload level can be unclear
• Many organizations lack the engineering maturity Fabric assumes

For some teams, Fabric will feel empowering. For others, it will introduce operational complexity. Both outcomes are valid.

What This Means for Your Power BI Setup Today

If you already follow Power BI best practices, you're not behind.

Keep Doing:

• Star schema modeling
• Thin reports over shared semantic models
• Certified datasets
• Clear Dev/Test/Prod separation

Start Evaluating:

• Centralized data in OneLake
• Dataflows Gen2 where reuse is required
• Capacity planning that accounts for non-BI workloads

Avoid:

• Rebuilding solutions "because Fabric"
• Mixing heavy ETL logic into Power BI models
• Assuming capacity will compensate for poor design

The Bottom Line

Power BI wasn't replaced — it was repositioned.

Fabric is:

• An architectural unification
• A platform-level shift
• A stress test for existing BI practices

For Power BI professionals, the message is simple: Fabric is not a reason to redesign your Power BI estate. It's a reason to validate whether your existing design was sound to begin with.

If your foundation is solid, Fabric isn't something you need to rush into. It's something you can adopt — deliberately, incrementally, and on your terms.

A Power BI Centre of Excellence (CoE) is not a reporting factory, and it's not a governance police force. At its best, it's a small, focused capability that enables scale: trusted data, consistent standards, and empowered report creators.

This guide outlines a pragmatic, experience-based approach to building a Power BI CoE that works in real organisations — aligned with Microsoft Power BI best practices, without unnecessary theory.

Step 1: Define the Purpose and Operating Model

Before defining tools, roles, or standards, be clear about why the CoE exists.

Most successful Power BI CoEs focus on:

• Improving trust in data and metrics
• Reducing duplication and rework
• Enabling self-service analytics safely
• Allowing Power BI usage to scale without chaos

Just as important is clarity on what the CoE is not:

• Not the only team allowed to build reports
• Not a mandatory gate for every dashboard

Define how the CoE engages

Many CoEs struggle because their engagement model is never explicit. Decide early:

• When the CoE advises vs approves vs owns assets
• Whether shared datasets are owned centrally or by domains
• How decisions are escalated when standards are challenged

If you can't describe the CoE's purpose and operating model in two sentences, it isn't ready to launch.

Step 2: Secure Executive Sponsorship (With the Right Framing)

Active executive sponsorship is a strong predictor of CoE success. Without it, standards quickly become optional.

What typically resonates with leaders:

• Reduced risk (data security, compliance, auditability)
• Faster, more confident decision-making
• Lower long-term cost through reuse and standardisation

What rarely resonates:

• Dataset design patterns
• Workspace naming conventions

Be explicit about what you're asking for:

• Visible sponsorship, not just initial approval
• Clear decision rights for standards and exceptions
• Time allocation for CoE members

Step 3: Start Small With the Right Roles (Not a Big Team)

You don't need a large team to start a CoE. Most effective CoEs begin with 3–6 people, often part-time, covering these roles:

• CoE Lead / Product Owner — prioritisation, stakeholder alignment
• Power BI Architect — semantic models, performance, scalability
• Platform or Tenant Admin — tenant settings, security, deployments
• Enablement Lead — training, documentation, community building

These are roles, not job titles. Over-staffing early often leads to over-engineering. Scale the team only once demand is proven.

Step 4: Establish Governance People Will Actually Follow

Governance fails when it's either too abstract or too restrictive. Anchor it in everyday Power BI work and make expectations clear.

Workspace strategy

Define a small number of workspace types with clear intent, for example:

• Personal / Sandbox — experimentation and learning
• Team / Department — collaborative delivery
• Certified / Endorsed — trusted, reusable content

Tie permissions, review expectations, and support levels to each type.

Dataset and model standards

Keep standards practical and enforceable:

• Clear naming conventions for measures
• Required descriptions for shared or certified models
• Performance expectations for reusable datasets

A simple certification checklist often works better than long documentation. For example:

• Refresh succeeds consistently
• Measures are documented
• Query performance meets agreed thresholds
• Security has been reviewed
• A named business owner exists

Change and release management

Not every change requires heavy process:

• Use Dev/Test/Prod for shared datasets
• Apply lightweight peer review for certified assets
• Define rollback expectations

Equally important is change communication. Define how breaking changes are announced, how long deprecations last, and where consumers can see what changed. Technical controls alone don't protect trust.

Step 5: Configure the Power BI Tenant Intentionally

The Power BI Admin Portal is where governance becomes enforceable.

Align tenant settings with your organisation's maturity:

• Be cautious with external sharing and publish-to-web early
• Control who can use premium features and create shared assets
• Enable audit logs and usage metrics from day one

Always document why each tenant setting exists. This prevents policy drift and helps future admins make informed changes.

Step 6: Enable Self-Service Instead of Fighting It

Self-service analytics will happen whether you plan for it or not. The CoE's role is to make the right way the easy way.

Effective enablement typically includes:

• Shared, well-designed semantic models
• Report templates with branding and layout guidance
• Short, task-focused training sessions

Community scales better than ticket queues. Internal user groups, office hours, Teams channels, and showcase sessions often deliver more value than formal support processes.

Step 7: Measure, Prove Value, and Evolve

A CoE should be treated as a product, not a one-time project.

Track platform metrics such as:

• Active users and creators
• Reuse of shared and certified datasets
• Support requests and performance issues

Over time, link these to business outcomes:

• Fewer duplicate reports
• Faster delivery of new insights
• Reduced dependency on central teams for ad-hoc requests

As maturity increases, successful CoEs typically loosen controls, shifting from enforcement to enablement.

Common CoE Failure Modes

• Lack of clear ownership — No one knows who owns shared datasets, standards, or decisions, leading to slow progress and conflict.
• Over-governance too early — Heavy approval processes and restrictive tenant settings drive users to work around the platform.
• CoE as a delivery factory — The CoE becomes the default report-building team, creating bottlenecks and burnout.
• Ignoring change management — Breaking changes land without warning, eroding trust in shared datasets.
• No success metrics — Without measurable outcomes, the CoE is eventually seen as overhead rather than value.

Final Thought

The most durable Power BI Centres of Excellence succeed because people want to follow the standards — not because they're forced to.

Start small, stay pragmatic, and optimise for trust over control. Perfect governance is rarely achievable; consistent, trusted insight at scale is.

If you've worked with Microsoft Power BI long enough, you know this pattern well: the model starts clean, measures are simple — and six months later, no one wants to open the measure pane.

This usually isn't because the business logic is hard. It's because the wrong DAX patterns were allowed to spread.

The five functions below aren't advanced tricks. They are foundational tools that, when used consistently, keep models understandable, performant, and safe for teams to evolve over time.

1. CALCULATE — The Engine Behind Context

CALCULATE is the most important function in DAX because it changes filter context. Almost every meaningful business measure relies on it, directly or indirectly.

Why it matters

• Enables time intelligence and conditional logic
• Allows measures to define their own business rules
• Keeps logic centralized instead of scattered across visuals

Example

CopySales – Online :=
CALCULATE (
    [Total Sales],
    'Sales'[Channel] = "Online"
)

This measure is explicit: the logic lives in DAX, not in report-level filters.

2. VAR — Readability First, Performance Second

VAR lets you store intermediate results inside a measure and reuse them cleanly.

Why it matters

• Makes measures easier to read and review
• Simplifies debugging and testing
• Can improve performance by avoiding repeated evaluation

Example

CopyProfit Margin :=
VAR Revenue = [Total Sales]
VAR Cost = [Total Cost]
RETURN
DIVIDE ( Revenue - Cost, Revenue )

This pattern is easier to reason about than a single dense expression — especially in team environments.

3. DIVIDE — Defensive DAX That Behaves Well in Reports

Division errors are a common cause of broken visuals and confused users. DIVIDE handles divide-by-zero scenarios safely and intentionally.

Why it matters

• Prevents errors without verbose logic
• Returns BLANK() by default, which behaves better in visuals
• Keeps measures concise and readable

Example

CopyProfit Margin :=
DIVIDE ( [Profit], [Total Sales] )

BLANK() values suppress misleading percentages in matrices and charts, instead of showing zeros that imply meaning.

4. SELECTEDVALUE — Safe Context Awareness

Interactive reports require measures to react to user selections. SELECTEDVALUE retrieves a single value only when exactly one exists, otherwise returning a defined fallback.

Why it matters

• Cleaner than VALUES + HASONEVALUE
• Prevents ambiguous or broken results
• Ideal for slicer-driven logic and dynamic labels

Example

CopySelected Year :=
SELECTEDVALUE ( 'Date'[Year], "Multiple Years" )

5. ALL and REMOVEFILTERS — Intentional Control of Filters

Some calculations must ignore parts of the filter context — totals, benchmarks, or contribution percentages. That's where filter-removal functions belong.

Why it matters

• Enables percent-of-total and share calculations
• Supports baselines and comparisons
• Keeps logic consistent across reports

Example

CopyTotal Sales (All Products) :=
CALCULATE (
    [Total Sales],
    REMOVEFILTERS ( 'Product' )
)

What Not to Do (Common Team Pitfalls)

Avoid these patterns — they're responsible for most fragile models:

• Embedding business logic in visuals instead of measures
• Nesting multiple CALCULATE calls without documenting intent
• Using / instead of DIVIDE in production measures
• Overusing SELECTEDVALUE where row context already exists
• Removing filters broadly (ALL(Table)) when only a column needs to be ignored
• Writing clever one-line measures that no one else can maintain

If a measure needs explaining in a meeting, it probably needs refactoring.

Final Thought: DAX Is a Team Discipline

These functions don't make a model "advanced" on their own. What matters is how consistently they're applied.

Strong BI teams:

• Centralize logic in measures
• Prefer clarity over cleverness
• Agree on filter-handling patterns
• Write DAX that explains itself

When your measures are readable, predictable, and performant, you reduce defects, speed up onboarding, and turn your semantic model into something the business can actually rely on.

This article is about how to write Power BI best practices that professionals will actually follow — grounded in Microsoft Power BI guidance, but shaped by real-world delivery in enterprise and shared-reporting environments.

Why Most Power BI Best Practices Fail

Most best practices don't fail because they're wrong. They fail because they're unusable.

Common problems include:

• Rules that are too abstract ("Use good naming conventions")
• Documents that are too long to reference while working
• Generic guidance copied directly from documentation
• Assumptions of ideal, greenfield projects that don't exist in reality

Power BI professionals work under time pressure, with evolving requirements and imperfect data. If a rule doesn't help them make a decision while building, it gets ignored.

Effective best practices are:

• Specific
• Actionable
• Easy to check in under a minute

Start From How Power BI Is Actually Used

Microsoft's Power BI guidance assumes a few realities that are worth embracing:

• Models grow over time
• Multiple developers touch the same dataset
• Performance problems often appear after adoption
• Business users rarely read documentation

Best practices should be written for living models, not theoretical ones. That means accounting for refactoring, handovers, and long-term support — not just first delivery.

Structure Best Practices Around Real Decisions

Developers don't think in categories like Modeling or Visualization. They think in questions:

• "Should this be a calculated column or a measure?"
• "Do I need a new table, or can I reuse an existing one?"
• "Is this DAX readable enough for someone else to maintain?"

Best practices should be structured to answer those questions directly.

Avoid this

Keep DAX simple.

Prefer this

If a measure contains multiple business rules, use variables and helper measures to improve readability, testing, and long-term maintenance.

The intent is the same — but the second version is something a developer can act on immediately.

Focus on the 20% That Causes 80% of Problems

Microsoft documentation is comprehensive. Your internal best practices shouldn't be.

Prioritize guidance that consistently causes issues in real projects:

• Poor data modeling
• Hard-to-maintain DAX
• Inconsistent naming and formatting
• Performance degradation at scale
• Loss of trust in reported numbers

For most Power BI teams, that usually means emphasizing:

• Star schema modeling
• Measure-driven calculations
• Avoiding unnecessary calculated columns
• Consistent naming and formatting conventions
• Careful use of bi-directional relationships

Be Precise About Measures vs Calculated Columns

A common source of confusion is when to use calculated columns versus measures.

A practical guideline looks like this:

• Prefer measures for aggregations and calculations evaluated at query time
• Avoid calculated columns on large fact tables where possible, as they increase model size and refresh cost
• Use calculated columns when values must be evaluated at refresh time, used in relationships, or exposed as slicers

This avoids dogma while aligning with how Power BI's engine actually works.

Make Performance Guidance Concrete — and Contextual

Performance advice is often ignored because it's vague or applied too early.

Instead of

Optimize your model for performance.

Be explicit and situational

• Disable Auto Date/Time in shared or enterprise datasets
• Reduce column cardinality where possible
• Hide unused columns from the report view
• Avoid bi-directional relationships unless there is a clear requirement
• Validate performance using Performance Analyzer before publishing

Treat Naming and Formatting as First-Class Practices

"Be consistent" isn't enough.

Good best practices provide examples, even if the exact standard varies by team.

For example:

• Use business-friendly names with spaces (not underscores)
• Avoid abbreviations unless they are widely understood by the business
• Keep measure names free of table prefixes
• Apply consistent number formatting at the model level

Clarity here improves usability, reduces confusion, and builds trust with report consumers.

Write for the Author, Not the Auditor

Best practices are rarely enforced by formal reviews. They're followed — or ignored — while someone is building a model.

That means they should be:

• Skimmable
• Short
• Written in plain language
• Easy to reference during development

If a developer can't quickly confirm a rule while writing DAX or modeling data, the rule won't be used.

Accept Constraints and Trade-Offs

Not every best practice can be applied in every situation.

Legacy data sources, organizational constraints, tight deadlines, and governance rules all force compromises. Good guidelines acknowledge this instead of pretending it doesn't happen.

The goal isn't theoretical perfection. It's consistency, transparency, and maintainability.

Keep Best Practices Alive

Power BI evolves constantly. So should your guidance.

To keep best practices relevant:

• Review them periodically
• Update them after major platform changes
• Adjust them based on real incidents and lessons learned

And make them easy to find:

• A short internal wiki page
• A README alongside shared datasets
• A pinned Teams or Slack post

The Real Goal

The purpose of Power BI best practices isn't to create flawless models.

It's to create predictable, understandable, and maintainable ones.

If your guidelines help someone make a better decision while building, they'll be followed.

If they can be checked quickly and explained easily, they'll last.

That's when best practices stop being rules — and start becoming shortcuts.