Power BI: show hydraulic results without hiding the exceptions

Decide what the dashboard should answer

The worked dashboard compares two synthetic scenarios at three nodes over four hourly timestamps. It should answer: what is the minimum modelled pressure, how many result rows are below a chosen threshold, which nodes are affected and when does the problem occur? The exercise uses pressure head in metres, not pressure in kPa.

Power BI presents and aggregates results; it does not solve a hydraulic network or certify compliance. Keep the model revision, scenario definition and adopted criteria with the exported data. The values in this exercise are constructed to test dashboard logic and are not outputs from a verified network model.

Import and establish the grain

1. In Power BI Desktop, use Get data → Text/CSV and select pressure_results.csv. Choose Transform Data so types and quality can be inspected before loading.
2. Name the query Results. Set Scenario and Node to text, Pressure_m to a decimal number, and Timestamp to an appropriate date/time type while preserving its UTC interpretation.
3. Confirm 24 rows and no missing values. Check that Scenario + Node + Timestamp uniquely identifies each row.
4. Inspect the two scenario names, three node names and four timestamps. Check that each scenario contains twelve observations.
5. Load the table and save the report with the source file in a documented location.

The grain is one node result per scenario per timestamp. If a pipe table or a customer table is later joined directly to it, one-to-many relationships can multiply rows. Aggregate or model relationships deliberately rather than combining every available table into one large flat result.

Use a simple data model and controlled filters

A single Results table is sufficient for this small exercise. For a larger project, separate node attributes, scenario descriptions and the time dimension from the result fact table. Use unique keys on the dimension side and relationships whose direction matches the intended filter flow. Avoid ambiguous many-to-many paths introduced merely to make a visual respond.

Create a Scenario slicer and set it to single selection for the first exercise. Add a Node slicer if useful. Keep the selected scenario visible in the report title or nearby text. A total computed across baseline and option results together is usually not a meaningful engineering performance statistic.

Where scenarios have different asset sets or time steps, define the comparison basis explicitly. Missing option results should not be converted to zero or interpreted as an improvement. Retain coverage measures and a clear indication of unavailable data.

Create measures with an explicit criterion

Create the following as separate measures on the Results table. The 20 m threshold is purely a teaching criterion, with a strict less-than comparison. Replace it with the adopted project criterion in real work and document whether equality is acceptable. The blank check avoids treating absent pressure as a low numeric value.

Minimum pressure m = MIN(Results[Pressure_m])

Result rows = COUNTROWS(Results)

Breach rows =
COALESCE(
    COUNTROWS(
        FILTER(Results,
            NOT ISBLANK(Results[Pressure_m]) &&
            Results[Pressure_m] < 20
        )
    ), 0
)

Affected nodes =
COALESCE(
    CALCULATE(
        DISTINCTCOUNT(Results[Node]),
        FILTER(Results,
            NOT ISBLANK(Results[Pressure_m]) &&
            Results[Pressure_m] < 20
        )
    ), 0
)

Minimum pressure is not an average. Breach rows count time-stamped observations. Affected nodes count distinct asset IDs within the selected context. These quantities answer different questions and should have different labels. A node that fails at two timestamps contributes two breach rows but only one affected node.

Assemble a report that exposes the mechanism

1. Add cards for Minimum pressure m, Result rows, Breach rows and Affected nodes.
2. Add a line chart with Timestamp on the horizontal axis, Pressure_m on the vertical axis and Node as the series. Use a single scenario selection and check the aggregation.
3. Add a table containing Scenario, Node, Timestamp and Pressure_m. Apply a visual filter or conditional formatting to identify values below 20 m.
4. Add an explicit criterion note, data units and a statement that the exercise is synthetic.
5. Change the scenario slicer and verify every visual responds consistently. Select one node and confirm that counts and minima update as expected.

Do not hide a local failure with an average across nodes. A map can help locate affected assets, but the time-series and row-level evidence are needed to understand duration and timing. Keep at least one table from which an engineer can recover the exact result.

Reconcile against the known answer

In BASE, J2 has one breach and J3 has two. Selecting J3 alone should produce a minimum of 17 m, two breach rows and one affected node. Selecting OPTION should produce zeros for the breach measures, not unexplained blanks.

The table counts observations, not continuous failure duration. Four hourly snapshots do not prove how long pressure stayed below a threshold between samples. To estimate duration, define the interval representation and interpolation policy. Do not label three breach rows as three hours unless the data and method support that interpretation.

Control refresh and scenario provenance

For an ongoing dashboard, establish a consistent export schema and folder structure. Retain a run identifier, model revision, export time, scenario description and source units. Use Power Query to reject or flag unexpected columns, duplicate keys and incomplete scenario coverage.

A refresh should not silently replace an approved baseline with an unreviewed run. Keep the distinction between draft, checked and issued results visible. Review refresh errors and show data currency in the report so a stale dataset is not mistaken for the latest assessment.

For confidential utility information, use the organisation’s approved Power BI sharing and access arrangement. The exercise does not require publishing a report to a public service. Exported reports and screenshots can also contain sensitive asset information, so their handling follows the project’s normal data rules.

Write the engineering interpretation beside the chart

A useful conclusion identifies the location, condition and governing mechanism. For this constructed dataset, the option values exceed the exercise threshold at every supplied row. That observation does not establish full network compliance, pressure adequacy between samples, storage replenishment, fire performance or water quality.

Use the dashboard to direct attention to the evidence and unresolved questions. Link the reported result to model purpose and validation and the scenario assessment. The data preparation behind this report is developed in the Python tutorial.

Sources & further reading

• Star schema guidance for Power BI ↗Microsoft · Living technical documentation
  External source · Checked 25 September 2026
• COUNTROWS function ↗Microsoft · Living DAX documentation
  External source · Checked 25 September 2026
• DISTINCTCOUNT function ↗Microsoft · Living DAX documentation
  External source · Checked 25 September 2026
• FILTER function ↗Microsoft · Living DAX documentation
  External source · Checked 25 September 2026

Source findings are distinguished from editorial interpretation. Apply current local criteria and project evidence when making engineering decisions.