Build a Power BI Metric Dictionary Your Property Ops Team Will Actually Use

Definitions before dashboards

Executives ask for one dashboard, but they mean three different numbers depending on who joined the call. A metric dictionary is the contract between SQL sources, DAX measures, and the decisions each role makes weekly.

Property and insurance operators benefit the same way brokerages do—when occupancy, exposure, and pipeline metrics have named owners and calculation notes.

What each row in the dictionary should include

Keep the dictionary in a table analysts can edit without opening the PBIX file—Excel, SharePoint list, or Fabric table with version history.

• Metric name as leadership says it aloud
• Business definition (one paragraph max)
• Grain: portfolio, property, unit, account
• SQL or Fabric source query ID
• DAX measure name in production model
• Owner and backup owner
• Refresh cadence and SLA

Write DAX for auditors, not only developers

Each measure note should explain filters applied, handling of nulls, and whether prior-period comparisons use the same grain. When underwriting asks why AAL moved, the answer should be in the dictionary—not in one analyst's inbox.

• Link to test cases (expected value ranges)
• Flag measures that must not be summed across grains
• Document known limitations after model refresh

Roll out with one executive view first

Ship a single summary page with three to five metrics before building department-specific pages. Adoption beats coverage when teams are skeptical of BI.

• Weekly standup uses dictionary names verbatim
• Red/yellow thresholds agreed with leadership
• Feedback loop logged before phase two views

Pair dictionary work with pipeline hygiene

If SQL exports still require manual merges every Monday, fix Fabric or SQL validation first. See our Fabric pipeline checklist for property data, or apply for a strategy session if you want a diagnostic on your stack.