Show an “Average Store” as a Bar: Building a Baseline Category in Power BI

Table of Contents

1. Key Highlights
2. Introduction
3. Why show a baseline as a category instead of a reference line?
4. The overall approach, explained at a glance
5. Power Query: adding the dummy row and filtering out outliers
6. Model considerations before building the visual
7. DAX: the conditional measure pattern and why CALCULATE inside AVERAGEX matters
8. Handling slicers and interaction design
9. Visual construction: clustered bar chart and formatting tips
10. Sorting and placement of the dummy row
11. Common pitfalls and how to avoid them
12. Alternatives to the dummy-row pattern
13. Real-world examples and use cases
14. Performance optimization strategies
15. Testing and validation checklist
16. UX and accessibility considerations
17. Documenting the solution and future-proofing
18. When to avoid the dummy-row approach
19. Troubleshooting checklist
20. Extending the pattern: baseline for other metrics and visuals
21. Practical example: step-by-step implementation (retail weekly sales)
22. Preparing for maintenance and handoff
23. FAQ

Key Highlights

• Use a dummy row in the Store dimension and a conditional DAX measure to present a baseline as a category inside a clustered bar chart instead of a reference line.
• The DAX pattern relies on SELECTEDVALUE to detect the dummy row and AVERAGEX with CALCULATE to force a correct context transition when computing the average across stores.
• Consider model design, filtering in Power Query, slicer interactions, and visual formatting to ensure the baseline behaves predictably and remains meaningful to stakeholders.

Introduction

Analysts frequently need to show how individual stores, teams, or products compare against an internal benchmark. A floating reference line can communicate that benchmark, but sometimes the audience reads a bar more naturally: a benchmark that appears as a peer category beside each store makes the comparison immediate and intuitive. That is the objective behind a clever Workout Wednesday challenge: add an “Average Store” bar to a clustered bar chart so the baseline behaves like any other category.

The visible chart is simple. The technique behind it is where the work sits: small changes in the data model, a filtering step in Power Query, and a conditional DAX measure that handles context transitions correctly. This article walks through the method step by step, explains why each element matters, shows code examples, covers alternatives and trade-offs, and offers testing and UX guidance so the final visual is robust and stakeholder-ready.

Why show a baseline as a category instead of a reference line?

A reference line is the default for benchmarks. It’s compact and visually unobtrusive, but it divorces the benchmark from the categorical story the chart tells. Presenting the benchmark as a category has several advantages:

• Cognitive fit: Non-technical audiences often scan category-by-category. A benchmark bar placed among categories maps directly to that mental model.
• Consistent legend and tooltip behavior: A benchmark bar can appear in the legend, respond to tooltips, and be formatted alongside categories for consistent interactions.
• Flexibility with sorting and grouping: The baseline can be sorted, grouped, or positioned deliberately among other categories to emphasize comparisons.
• Filter behavior control: The measure that creates the baseline can be designed to respond or ignore slicers and filters, giving predictable behavior depending on business requirements.

Those benefits come at the cost of a little extra modelling work. The rest of this article explains the minimal, repeatable steps needed to implement this pattern and avoid common pitfalls.

The overall approach, explained at a glance

There are three coordinated changes to make:

1. Add a dummy row to the Store table (for example, Description = "Average Store") so it appears in the axis of the chart like any other store.
2. Prevent store-level outliers (such as a special online store keyed 999999) from distorting the calculated average by filtering those rows in Power Query or handling them in DAX.
3. Create a conditional DAX measure that returns SUM(Sales[Quantity]) for real stores but returns an average across stores for the dummy row. The average calculation must use AVERAGEX with CALCULATE to perform a context transition so each store’s sum is evaluated correctly.

Those components produce a clustered bar chart where each store has a bar and the “Average Store” appears as a bar that represents the benchmark.

Power Query: adding the dummy row and filtering out outliers

Start in the Store table. The dummy row must exist in the model as a proper row with a StoreKey and a Description, not as a calculated measure or a visual hack. There are two common ways to add it:

• Create the dummy row in the source data and bring it through ETL.
• Add the dummy row in Power Query using an Append operation.

Either approach works. Adding it in Power Query is convenient and keeps the change contained to the model.

Example Power Query (M) pattern to append a dummy row:

let
    Source = Sql.Database("server", "database", [Query="SELECT StoreKey, Description, Region FROM dbo.Store"]),
    StoreTable = Table.TransformColumnTypes(Source, {{"StoreKey", Int64.Type}, {"Description", type text}, {"Region", type text}}),
    DummyRow = #table(
        Table.ColumnNames(StoreTable),
        {{999998, "Average Store", null}}
    ),
    Appended = Table.Combine({StoreTable, DummyRow}),
    // Filter out the online sales store if present in Store table or if part of Sales table join logic
    Filtered = Table.SelectRows(Appended, each [StoreKey] <> 999999)
in
    Filtered

Key points:

• Use an obviously out-of-range key for the dummy row (999998 in the example) to avoid collisions.
• If the sales dataset includes a special online-store key (999999 in the source article), filter it out so the average calculation is not skewed.
• If you prefer not to remove the online store from the Store table, you can remove it in the Sales query so it does not contribute values; choose whatever aligns with governance and audit requirements.

After this step, refresh the model and confirm the new "Average Store" row appears in the Store table.

Model considerations before building the visual

Two small but important modeling details:

• Relationships: The dummy store row typically has no Sales rows. That’s fine. The Store table should remain related to Sales by StoreKey. Because the dummy row won't have matching Sales entries, the SUM path will return BLANK for the dummy row unless the measure computes the average explicitly.
• Hide unnecessary columns: If you add a SortOrder or flag column (recommended later), hide it from report view if you don't want it selectable by users.
• Slicer interaction: Decide whether the baseline should be dynamic (recalculate when users apply slicers) or fixed (global average independent of slicers). That choice changes the DAX you write. For stakeholder reports, dynamic baselines are often preferable because the benchmark reflects the filtered set. When the baseline must remain fixed, use ALL/ALLEXCEPT in the measure.

DAX: the conditional measure pattern and why CALCULATE inside AVERAGEX matters

The core of the solution is a measure that behaves differently when the current category is the dummy row. That requires checking the axis value and returning either SUM for normal rows or an average for the dummy row.

A straightforward but robust measure looks like this:

Quantity with Baseline =
IF(
    SELECTEDVALUE(Store[Description]) = "Average Store",
    AVERAGEX(
        VALUES(Store[StoreKey]),
        CALCULATE(SUM(Sales[Quantity]))
    ),
    SUM(Sales[Quantity])
)

Why this works:

• SELECTEDVALUE(Store[Description]) reads the currently selected store description on the axis. When the chart is rendering the "Average Store" row, the condition is true and the measure evaluates the average branch.
• AVERAGEX iterates across the set of stores returned by VALUES(Store[StoreKey]). For each store key, CALCULATE(SUM(Sales[Quantity])) forces a context transition. Without CALCULATE, SUM would evaluate in the outer context (which for the dummy row may include no store filter), producing an incorrect result.
• For normal store rows, the measure simply returns SUM(Sales[Quantity]).

Common variants and refinements

• Exclude the dummy row from the AVERAGEX loop explicitly to avoid counting it when computing the average:

AVERAGEX(
    FILTER(VALUES(Store[StoreKey]), Store[Description] <> "Average Store"),
    CALCULATE(SUM(Sales[Quantity]))
)

• If you need the average to ignore slicers on Store or Region (i.e., a fixed, global benchmark), use ALL(Store) inside CALCULATE:

AVERAGEX(
    FILTER(ALL(Store[StoreKey]), Store[Description] <> "Average Store"),
    CALCULATE(SUM(Sales[Quantity]))
)

• If you want the baseline to respond to other slicers (date or product), restrict ALL to Store only:

AVERAGEX(
    FILTER(ALL(Store), Store[Description] <> "Average Store"),
    CALCULATE(SUM(Sales[Quantity]))
)

Understanding context transition This pattern rests on the difference between row context and filter context. AVERAGEX creates a row context for each store key. CALCULATE converts that row context into a filter context so that SUM(Sales[Quantity]) evaluates the quantity for that particular store. Without CALCULATE, SUM may evaluate using the outer filter context (for the dummy row that often has no store filter), resulting in the same value being used repeatedly and producing a misleading average.

Using variables for clarity and performance Introduce variables to avoid repeated evaluation and improve readability:

Quantity with Baseline =
VAR CurrentStore = SELECTEDVALUE(Store[Description])
VAR Baseline =
    AVERAGEX(
        FILTER(VALUES(Store[StoreKey]), Store[Description] <> "Average Store"),
        CALCULATE(SUM(Sales[Quantity]))
    )
RETURN
IF(CurrentStore = "Average Store", Baseline, SUM(Sales[Quantity]))

Variables also make it easier to instrument and debug measures during testing.

Handling slicers and interaction design

Decide how filters should affect the baseline. Two common behaviors:

1. Dynamic baseline: The benchmark recalculates based on all filters except the axis itself. If a user filters the chart to a region or a date, the average should reflect that restriction. Implement by keeping the FILTER scope narrow and avoid ALL on slicers you want to respect.
2. Fixed baseline: The benchmark is global and does not change with slicers (useful when you compare current filtered results against a company-wide target). Implement using ALL(Store) or ALL(Table) inside the baseline calculation.

Examples:

• Baseline that respects date slicer but ignores Store slicer:

Baseline =
AVERAGEX(
    FILTER(ALL(Store), Store[Description] <> "Average Store"),
    CALCULATE(SUM(Sales[Quantity]))
)

This uses ALL(Store) to remove store filters but leaves date slicers intact because they are not in ALL.

• Baseline that ignores all slicers (global):

Baseline =
AVERAGEX(
    FILTER(ALL(Store), Store[Description] <> "Average Store"),
    CALCULATE(SUMX(ALL(Sales), Sales[Quantity]))
)

Use these patterns carefully. Make decisions based on business rules: do users expect the benchmark to reflect their selected time window? Often they do for fairness. Document the choice.

Visual construction: clustered bar chart and formatting tips

After creating the measure and ensuring the dummy row exists in Store, build the visual:

• Axis: Put Store[Description] (or StoreName) on the axis.
• Value: Use the measure Quantity with Baseline.
• Sort: You may want the "Average Store" to appear first or last. Create a SortOrder column in the Store table (1..N and a specific value for the dummy row) and use it to control sort order.
• Highlighting: Format the "Average Store" bar in a contrasting colour to make the baseline unmistakable. Use conditional formatting to assign a specific color when the store description equals "Average Store."

Conditional color DAX measure (returns hex color):

Color for Store =
VAR Desc = SELECTEDVALUE(Store[Description])
RETURN
IF(Desc = "Average Store", "#FF7F00", "#3778BF")

Use this measure in the chart's Data colors conditional formatting (Format > Data colors > Based on field). Pick accessible colours with sufficient contrast for readability.

• Data labels and tooltips: Show the numeric value on the bar and customize the tooltip to state explicitly that the bar for "Average Store" is an average across stores. Add a tooltip page if you need to show the calculation details.
• Legend and axis labeling: Because a baseline bar might be misread as an actual store, include an annotation (text box) or legend entry clarifying that "Average Store" is a computed benchmark.

Sorting and placement of the dummy row

By default, the axis will sort alphabetically or by measure value. To control where the baseline appears, add a SortOrder column to the Store table:

• Assign incremental numeric values to real stores.
• Assign a desired number for the dummy row (e.g., 0 to put it first, 9999 to put it last).
• In Power BI Desktop, sort Store[Description] by Store[SortOrder] (Modeling > Sort by Column).

This ensures the baseline appears exactly where stakeholders expect it.

Common pitfalls and how to avoid them

1. Baseline equals the same value as every store (common bug)
   • Cause: omitting CALCULATE inside AVERAGEX so SUM evaluates in the wrong context.
   • Fix: wrap SUM in CALCULATE(CALCULATE(SUM(Sales[Quantity])))? No—just CALCULATE(SUM(Sales[Quantity])) inside the iterator.
2. Baseline is distorted by outliers
   • Cause: an online or special store included in the average.
   • Fix: filter out that store in Power Query or exclude it explicitly in the AVERAGEX filter.
3. Baseline disappears under slicers
   • Cause: slicer filters the Store table and removes the dummy row from the visual context.
   • Fix: ensure the dummy row meets slicer conditions (e.g., give it Region = "All Regions" or adjust slicer logic) or move the baseline measure to a disconnected table rather than a store row. Alternatively, use ALL in the AVERAGEX when needed.
4. Sorting places the dummy row unpredictably
   • Cause: no explicit SortOrder.
   • Fix: add and use a SortOrder column.
5. Performance issues on large models
   • Cause: iterating over many store rows with heavy calculations.
   • Fix: use SUMMARIZE to reduce the iteration set or pre-aggregate in Power Query/aggregate tables. Store precomputed aggregates if needed.

Alternatives to the dummy-row pattern

This approach is not the only way. Consider alternatives and their trade-offs:

• Reference line: Quick to build and computationally lightweight. Less intuitive for audiences who prefer category comparisons.
• Disconnected table: Create a separate table of categories including "Average Store" and write measures that lookup the category. This keeps the Store dimension pure but requires careful relationship handling.
• Calculation groups (Tabular Editor): Use calculation items to create multiple perspectives of the metric (e.g., Actual and Average) and display them as columns in a matrix. Useful for advanced scenarios but requires premium tooling and expertise.
• Scatter or combo charts: For certain comparisons (e.g., comparing two metrics), a floating benchmark could make more sense.

Choose the approach that balances usability, maintainability, and performance for the reporting environment.

Real-world examples and use cases

Retail chain performance dashboard

• Scenario: Regional managers want to see each store’s weekly sales with a company-wide weekly average shown as a bar. They prefer seeing the average as a store-like column to make quick pairwise comparisons.
• Implementation: Add "Average Store" row, exclude online stores from Sales in Power Query, create conditional measure dynamic to date slicer so weekly averages update, and format the baseline in a distinct orange with text annotation.

Sales team leaderboard

• Scenario: Sales reps compare monthly closed deals against an internal benchmark. The baseline should reflect the average among active reps only.
• Implementation: Exclude inactive reps in the average calculation (FILTER(VALUES(Rep[RepKey]), Rep[ActiveFlag] = 1)) and ensure the baseline updates when managers filter by territory.

Product category performance

• Scenario: Product managers want to compare each SKU’s return rate against the average for that product category.
• Implementation: Add “Average SKU” at the category level, compute the average return rate with AVERAGEX over SKUs within the category, and display in a clustered bar so SKUs and the category average appear together.

Each case requires small adjustments (different filters, different fields to average). The pattern persists: provide a visible category for the benchmark and a measure that branches behavior.

Performance optimization strategies

The pattern is lightweight for small to medium models but consider these optimizations for large models:

• Pre-aggregate: Build a store-level aggregated table in Power Query or as a summary table in the model, then run AVERAGEX across that summary. This minimizes row-level calculations at runtime.
• Reduce iterator cardinality: Replace VALUES(Store[StoreKey]) with a smaller summary set, like SUMMARIZE(Store, Store[StoreKey], "StoreQuantity", CALCULATE(SUM(Sales[Quantity]))). Then AVERAGEX over that summarized table.
• Use calculated columns selectively: Avoid storing dynamic measures as calculated columns; keep them as measures to preserve responsiveness to slicers if needed.
• Monitor DAX Studio: Use DAX Studio or the Performance Analyzer in Power BI Desktop to inspect query plans and refine slow measures.

Example of pre-aggregating with SUMMARIZE inside the measure:

BaselineOptimized =
VAR StoreSummaries =
    SUMMARIZE(
        FILTER(ALL(Store), Store[Description] <> "Average Store"),
        Store[StoreKey],
        "Qty", CALCULATE(SUM(Sales[Quantity]))
    )
RETURN
AVERAGEX(StoreSummaries, [Qty])

This reduces the work inside AVERAGEX by precomputing the per-store total once.

Testing and validation checklist

Before handing a report to stakeholders, validate the baseline behavior:

• Test with and without slicers (date, region, product) to confirm expected baseline dynamics.
• Compare baseline values against a separate manual calculation (Excel or a quick DAX measure) to confirm correctness.
• Verify that the dummy row does not inadvertently appear in store-level filters if that would confuse end users.
• Confirm that the average excludes intended outliers (online store, test stores).
• Test sorting and ensure the baseline appears where designed.
• Check color contrast and text readability with common accessibility tools.

Document each decision—why the baseline is dynamic or fixed, which stores were excluded, and how the metric was calculated—so report consumers and auditors understand the behavior.

UX and accessibility considerations

A visual that mixes real entities and computed categories risks misinterpretation. Reduce ambiguity:

• Label the dummy row clearly: "Average Store (benchmark)" or "Company Average".
• Use consistent visual affordances: color for computed items, icons or tooltips.
• Provide a short note near the chart: "Benchmark is the average across active stores; excludes online store."
• Ensure color choices meet WCAG contrast requirements; use textures or patterns for viewers with color vision deficiencies if necessary.
• Make the baseline discoverable in the legend and in tooltip information.

Good UX reduces helpdesk traffic and improves stakeholder trust.

Documenting the solution and future-proofing

Add model documentation and in-report explanations:

• Model metadata: In Power BI, use Description fields for measures and columns to explain purpose.
• Report notes: A documentation page that explains data sources, transformations (e.g., addition of dummy row), and measure logic.
• Version control: If your organization uses deployment pipelines, record the change in release notes so downstream reports or ETL processes remain aligned.

Anticipate future changes:

• If the business later adds another baseline (median or target), build the Store table so additional computed rows can be appended easily.
• Encapsulate baseline logic into reusable measures or calculation templates so other developers can replicate the approach.

When to avoid the dummy-row approach

This pattern is not always appropriate:

• Large cardinality dimensions with thousands of categories: the extra iteration can degrade performance.
• When the baseline must represent a more complex aggregation (weighted average, median): additional DAX complexity may make a reference line or separate visual more straightforward.
• If the benchmark needs to be part of a different aggregation level (e.g., company average versus category average), consider a separate summary visual or calculation group.

If any of these conditions apply, evaluate alternatives (reference lines, disconnected tables, pre-aggregated summary tables) before committing.

Troubleshooting checklist

If the baseline does not behave as expected, step through these checks:

• Is the dummy row present in the Store table and not accidentally filtered out by the report or slicers?
• Does the measure correctly identify the dummy row (exact string match, casing, trailing spaces)? Use TRIM and UPPER/LOWER to standardize comparisons if necessary.
• Is CALCULATE used inside the AVERAGEX iterator to enforce context transition?
• Are there unintended filters (bidirectional relationships, slicers on related tables) affecting the calculation?
• If baseline equals same value everywhere, examine the measure in DAX Studio for the filter context and run Evaluate to inspect intermediate tables.
• Check whether the online store key (e.g., 999999) remains in Sales and is being unintentionally averaged.

A methodical check of model, measure, and visual settings usually finds the issue quickly.

Extending the pattern: baseline for other metrics and visuals

This pattern generalizes to many metrics and visual types.

• Percentage metrics: Baseline can represent average return rate or conversion rate. Use DIVIDE to avoid division by zero.
• Multiple baselines: Add separate dummy rows for "Median Store" or "Top Quartile Store." Each requires its own measure or logic branch.
• Matrix visuals: In a matrix, the dummy row can appear as one of the rows or columns when the dimension is used. Adjust measure logic to account for matrix row/column contexts.
• Sparkline or small-multiple visuals: Place the baseline as an extra small-multiple for each member to show comparison consistently.

Design with logical naming conventions to keep measures manageable as the number of baselines grows.

Practical example: step-by-step implementation (retail weekly sales)

This is a concrete walkthrough for a retail weekly sales report.

1. Power Query
   • Load Store and Sales tables.
   • Append dummy row to Store: StoreKey = 999998, Description = "Average Store".
   • Filter out StoreKey = 999999 (online store) from Sales to exclude it from averages.
2. Model
   • Relationships: Store[StoreKey] -> Sales[StoreKey] one-to-many.
   • Add SortOrder column in Store: numeric sequence for natural sort, dummy row gets 0.
3. DAX measure

Weekly Quantity with Baseline =
VAR CurrDesc = SELECTEDVALUE(Store[Description])
VAR Baseline =
    AVERAGEX(
        FILTER(VALUES(Store[StoreKey]), Store[Description] <> "Average Store"),
        CALCULATE(SUM(Sales[Quantity]))
    )
RETURN
IF(CurrDesc = "Average Store", Baseline, SUM(Sales[Quantity]))

4. Visual
   • Create clustered bar chart.
   • Axis: Store[Description] (sorted by Store[SortOrder]).
   • Value: Weekly Quantity with Baseline.
   • Conditional color measure for data colors to differentiate baseline.
   • Add data labels and customize tooltip to include "Benchmark: average across stores."
5. Validation
   • Compare the baseline value to a separate measure that computes the average explicitly and inspect results for several filters.
6. Documentation
   • Add a text card describing how the baseline was computed and which stores are excluded.

This example maps directly to the Workout Wednesday challenge, with attention to SAP (sales) dataset specifics and operational details.

Preparing for maintenance and handoff

When handing the report to a business user or another developer, include:

• A short README page inside the report that describes the added dummy row, the reason for filtering out online store keys, and the exact DAX expression for the baseline.
• Clear measure names: prefix baseline measures with "Baseline -" or suffix with "(computed)" so they stand out.
• A change log entry describing when and why the dummy row was added.

Good documentation reduces future errors and speeds up onboarding.

FAQ

Q: Why add a dummy row instead of using a reference line? A: A dummy row lets the baseline appear as a category, which is often easier for audiences to interpret when they scan categories. A reference line functions differently in legend, tooltips, and relative sorting. Use the dummy row when the benchmark must behave like a comparative category.

Q: Why does the DAX use CALCULATE inside AVERAGEX? A: AVERAGEX creates a row context for each store key. CALCULATE converts that row context into a filter context so SUM(Sales[Quantity]) evaluates for each specific store. Without CALCULATE, SUM would evaluate in the outer context and produce an incorrect average.

Q: How do I prevent the online store (e.g., storekey = 999999) from skewing the average? A: Remove or filter out that store in Power Query (recommended) or exclude it explicitly inside the AVERAGEX filter: FILTER(VALUES(Store[StoreKey]), Store[StoreKey] <> 999999).

Q: Should the baseline be dynamic with slicers or fixed? A: Choose based on business needs. If users expect the benchmark to reflect applied slicers (date, region), keep it dynamic by not using ALL on those slicers. If the benchmark must be global, use ALL(Store) or appropriate clearing of filters in the baseline calculation.

Q: My baseline shows the same value for every row. What went wrong? A: Most likely CALCULATE is missing inside the AVERAGEX iterator. Ensure the iterator's expression uses CALCULATE(SUM(Sales[Quantity])) so the sum evaluates per store.

Q: How can I control where the "Average Store" appears in the axis? A: Add a SortOrder column to the Store table and use Sort by Column to sort Store[Description] by Store[SortOrder]. Assign a value for the dummy row to position it first or last.

Q: Are there performance concerns with this pattern? A: For small to medium models it’s fine. For large cardinality dimensions, pre-aggregate store totals in Power Query or use SUMMARIZE inside the measure to reduce iteration. Profile with DAX Studio if performance degrades.

Q: Can I show other baselines (median, weighted average)? A: Yes. The same pattern applies: compute the desired statistic inside the conditional branch and present a dummy row per baseline type. Compute medians using PERCENTILEX.INC or other advanced functions, and weight averages by including weights in the iterator expression.

Q: How do I make the baseline accessible and understandable to non-technical users? A: Label the row clearly, use a distinct color, add a tooltip or annotation that explains how the baseline is computed, and document exclusions (e.g., online stores) and filter behavior.

Q: What if the Baseline should ignore slicers on stores but respect dates? A: Use ALL(Store) inside the baseline iterator to clear store filters but leave date filters intact; for example, iterate over FILTER(ALL(Store), Store[Description] <> "Average Store") and then CALCULATE(SUM(Sales[Quantity])) which will still respect slicers on date.

Q: Can this technique be used in other BI tools? A: The concept translates: create a synthetic category in the dimension and compute a conditional metric that returns the aggregated statistic for that synthetic category. Implementation specifics vary by tool but the pattern remains applicable.

Q: How do I test the correctness of the baseline? A: Create a separate validation measure or export raw numbers to Excel and compute the average independently. Test the baseline under different slicer combinations and confirm expected behavior.

Q: Is the dummy row audited or traceable? A: Yes. Model documentation should record the presence of synthetic rows and their purpose. If governance requires traceability at the source, consider populating the dummy row in source ETL rather than ad-hoc in Power Query so source control captures the change.

Q: What naming convention should I use for the dummy row? A: Use clear, business-friendly labels such as "Company Average (benchmark)" rather than cryptic names. This helps end users interpret the visual correctly.

Q: Can I combine this with bookmarks or drill actions? A: Yes. Use bookmarks to toggle between different baseline presentations (bar vs. reference line) or to reveal explanatory text. Drillthrough and tooltips work normally, but ensure the baseline’s tooltip clarifies that it’s a computed benchmark.

Q: What if users want to compare each store to the baseline as a percentage difference? A: Create an additional measure that computes the percent difference relative to the baseline. Use the baseline measure as the denominator in DIVIDE to produce the percent difference for normal stores and BLANK for the baseline row itself.

This pattern gives analysts a straightforward way to make a benchmark feel like a category, improving readability for many audiences. The technique balances small model changes with thoughtful DAX logic and deliberate visual design. Implement, test, and document the choice so the final report is both accurate and easy for stakeholders to use.