Using the Wireframe Pattern

by

1. Purpose

This guide shows how to build a Power BI report using the standard DataMart wireframe.

It demonstrates how:

  • Data Engineering provides structured, governed data
  • Analysts shape that data into insight using parameters
  • Both operate together without conflict

The wireframe is not just a template — it is a working example of how reporting should be built.

Please download your own version from here…

https://app.powerbi.com/groups/3974c1cc-9a5c-4af9-b717-379013d17d53/reports/08af53f0-f4c9-41d8-b85e-c0f597947bf7/ReportSection?ctid=b52d5b10-ca0e-48a0-86ab-0a34fd628e8b&experience=power-bi

2. The Principle

Engineering defines the data.
Analysts define the question.
The wireframe allows both to operate without conflict.

3. What you are working with

The wireframe report already contains:

Data access (handled for you)

  • fnGetMyView(...)
  • environment resolution (DataMart_env)
  • token handling (Report_Title)

Standard DataMart views

  • core_details
  • meta_codes
  • meta_dates
  • meta_values

A reporting layer

  • parameter-driven slicers
  • parameter-driven date selection
  • parameter-driven measure selection

4. What you need to do as an analyst

You are not building connections or SQL.

You are answering four questions:

1. What am I analysing?

Set:

param_DataMart

Example:

  • Project
  • Order
  • Invoice

2. How do I want to group it?

Set:

param_Slicer1
param_Slicer2

Examples:

  • STATUS_LIFECYCLE
  • TYPE_CATEGORY
  • PROGRAMME_BUSINESS

3. What defines time?

Set:

param_Date

Examples:

  • DERIVED_Start_Date
  • DATE_CREATED
  • DATE_CLOSED

4. What am I measuring?

Set:

param_DisplayValue

Examples:

  • COST_ACTUAL
  • REVENUE_TOTAL
  • HOURS_WORKED

That’s it.

Everything else is already handled.

5. What the wireframe is doing (behind the scenes)

You don’t need to modify this — but you should understand it.

Step 1 – Retrieve data

fnGetMyView(DataMart, ViewName, Version)

This ensures:

  • correct environment
  • correct access
  • consistent structure

Step 2 – Translate metadata into columns

META_TYPE + ATTRIBUTE → CODE_ATTRIBUTE

Example:

STATUS + LIFECYCLE → STATUS_LIFECYCLE

Step 3 – Pivot into report format

Attributes become columns:

STATUS_LIFECYCLE
TYPE_CATEGORY
PROGRAMME_BUSINESS

Step 4 – Apply your selections

The model dynamically uses your chosen:

  • slicers
  • date
  • measure

to produce the final dataset.

6. Example using the wireframe

Scenario:

“Show actual cost by programme over time”

Set:

param_DataMart      = Project
param_Slicer1       = PROGRAMME_BUSINESS
param_Date          = DERIVED_Start_Date
param_DisplayValue  = COST_ACTUAL

Result:

  • X-axis → date
  • Y-axis → cost
  • Grouping → programme

No SQL. No restructuring. Just parameter selection.

7. What this enables (this is the real value)

Using the same model, you can now answer:

  • Cost by programme
  • Revenue by customer
  • Pipeline by lifecycle status
  • Hours by project type

without rebuilding the report.

8. Rules for using the wireframe

DoDon’t
✔ Change parameters to explore different views
✔ Use standard attributes (STATUS, TYPE, PROGRAMME, etc.)
✔ Validate what a field means before using it
✔ Reuse the model across different questions		✖ Modify fnGetMyView
✖ Hardcode connections or SQL
✖ Assume all values can be summed
✖ Assume all attributes exist in all DataMarts

9. Common pitfalls

“Column not found”Your parameter doesn’t match a real attribute.→ Check spelling and availability
“Unexpected results”You selected the wrong attribute or value type.→ Check meaning, not just name
“Numbers don’t add up”Not all values are additive.→ Confirm aggregation logic
“Column disappeared”Pivoted columns depend on data.→ Attribute may not exist in current dataset

10. What this teaches (important)

This wireframe is not just a report.

It teaches you to think in terms of:

  • objects (Project, Order, Invoice)
  • attributes (Status, Type, Programme)
  • measures (Cost, Revenue, Hours)
  • time (Start Date, Close Date)

This is the same structure used by the Data Engineering platform.

11. How this fits into the bigger picture

This pattern:

  • aligns reporting with DataMart design
  • reduces duplication and inconsistency
  • allows governed self-service
  • supports scalable reporting across domains

12. Summary

The wireframe demonstrates how to:

  • use a standard DataMart
  • retrieve data through a governed function
  • shape metadata into report columns
  • build flexible reports using parameters

It is both:

  • a working report
  • a reference model for how reporting should be built

Leave a Comment