Dashboard documentation template: explain a changed denominator

A completion tile rises from 50% to 66.67%, although no request closed. Document the IDs behind both fractions before describing that rise as better performance.

The D01 example starts with Q01 Closed, Q02 Closed, Q03 Open, and Q04 Unknown. Metric M01 v1 counts two closed requests among all four, giving 50%. Proposed v2 excludes unknown status and gives 2/3, about 66.67%. The HTML review switches between those definitions, filters actual supplied statuses, and demonstrates why a conflicting duplicate must stop a recompute.

Explain the denominator.
Explain the denominator.
Open the full example ↗

Define one source row

S01 promises one current row per unique request ID, as of October 13, 2026. That grain makes four rows equivalent to four distinct requests in the consistent example. Event-history rows would need a different rule before they could represent current status.

Write down the ID field, allowed status values, as-of rule, duplicate policy, source location, owner, and update method. The example supplies only the grain, date, IDs, and statuses. Its actual owner, connection, and refresh record remain unconfirmed.

Microsoft's dashboard concepts documentation separates datasets, calculations, and visualization filters. Use that distinction to organize the handoff: describe where rows come from, what the calculation means, and which rows a view includes. Platform-specific features do not need to become part of your template.

Give the metric a versioned definition

M01 v1 is closed unique requests divided by all in-scope unique requests. Q01 and Q02 form the numerator. Q01 through Q04 form the denominator. Unknown status stays outside the numerator but inside the denominator, so 2/4 × 100 = 50%.

Show the unknown count separately as M02: one request, Q04. That gives a maintainer a direct way to inspect missing status instead of inferring it from the completion percentage.

Proposed M01 v2 uses known-status requests only. Its denominator is Q01, Q02, and Q03. The numerator remains Q01 and Q02, producing 2/3 × 100, approximately 66.67%. Record v2 as a proposal pending owner review. The calculation changed; the source facts did not.

Make each filter reproduce its own fraction

The local buttons filter the statuses actually supplied in S01. Under v1, Closed shows 2/2 = 100%, Open shows 0/1 = 0%, and Unknown shows 0/1 = 0%. The view lists the included IDs beside the fraction.

Under v2, the Unknown-only view has no eligible denominator. Display "Undefined: no eligible requests" instead of 0%. That wording separates a calculation with no base from a valid zero numerator over a positive base.

The source contains no category values. A category filter therefore needs additional source data before it can produce a meaningful result. Do not invent departments or retain the overall denominator while labeling it category-specific.

Hold the calculation when the source conflicts

The conflict button introduces a second Q01 row with Open status while the original Q01 remains Closed. Both are retained for inspection. One current row per ID is now broken. The example withholds the current metric until the conflict is removed.

Do not count that row as a fifth request or choose whichever status makes the result look plausible. Ask the source owner to reconcile the records, keeping their references. The baseline's 50% remains a worked result for the consistent fixture, not a verified answer for contradictory data.

Copy this prompt

Create a single-file US-English HTML metric-definition review for fictional dashboard D01. Use a documentation-workbench design, readable source rows, definition tabs, and a prominent fraction with counted IDs. Minimum text size 16px; responsive at 360px. Include all code locally without remote dependencies or persistence.

Source S01 is one current row per unique request ID, date-only as of October 13, 2026. Rows: Q01 Closed, Q02 Closed, Q03 Open, Q04 Unknown. Actual owner, source location, access, and verified refresh remain unconfirmed.

Default M01 v1 divides closed unique IDs by all in-scope unique IDs. Show 2/4 = 50%, with unknown included. M02 unknown count is one, Q04. Proposed M01 v2 divides closed by known-status IDs: 2/3 = approximately 66.67%. Clearly label it proposed and pending owner review; no request closed when switching versions.

Use type=button controls for version selection and All/Closed/Open/Unknown status filtering. Recompute from the selected supplied IDs; display numerator and denominator IDs. Under v2 with Unknown selected, show an undefined no-eligible-denominator state. Do not invent category values.

Add a conflict scenario button that retains an additional Q01 Open record alongside Q01 Closed. Withhold the metric while this violates the one-current-row grain, show the conflicting references, and allow returning to the consistent fixture. Never silently deduplicate or count it as a fifth request.

Include concise source-contract, tile-definition, and change-note sections. All interactions are local review only: no live refresh, data connection, operational metric changes, approvals, or saved records. Use accessible buttons with visible state and explicit selectors. Return complete HTML.

Keep the source contract, metric dictionary, filter map, and definition changelog in the documentation repository. Before changing a production tile, review its label and denominator with the owner. A sanitized HTML comparison in NOS can preview the two definitions together, helping that discussion stay attached to Q01 through Q04 rather than to an unexplained percentage.

Keep reading