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.

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