BI course 03 — Testing filters, freshness and audience access

A report is ready for use only when its scope, changing data and audience have been checked. This chapter gives a controlled test method that remains useful when native BI execution is unavailable. It distinguishes calculated expectations from observed application results.

In this chapter

• Record a baseline before changing a filter
• Verify restoration as a result
• Distinguish change in work from change in coverage
• Prepare different packets for different readers
• Verify the intended audience through supported access
• End with an honest release decision

Record a baseline before changing a filter

For the three-item practice register, record the baseline IDs A/B/C, cutoff 10:00, ready A, and rate 1/3. Then change one analytical variable at a time. Restricting due date to Friday should include A/B, exclude C and produce 1/2. Restoring the full population should restore A/B/C and 1/3.

A dashboard-list search finds a dashboard. It does not filter that dashboard's data. Selecting a BI space changes visible context, but does not prove data isolation or viewer permissions. A native data filter needs its own applied-value and settled-result check.

Before declaring a filter correct, compare both the metric and included identities. If the result remains 50 percent but the population changes from A/B to A/C, the numerical equality conceals an error. If the interface cannot expose enough source detail to reconcile the answer, keep that verification limitation explicit.

Verify restoration as a result

Typing the original filter values is not restoration. A supported confirmation action, applied filter label and settled result must agree with the baseline. If a browser closes before confirmation, inspect the actual current state before reporting it restored.

Do not broaden the range blindly to make a chart nonempty. An empty result can be correct for a narrow period. Check the question, source date field and boundaries before deciding it is an error. A loading failure is not an empty population.

The current BI shell does not provide a demonstrated populated-filter test. These calculations specify what a later authorized test must compare; they do not establish that BI's Last 30 days control has been executed successfully.

Distinguish change in work from change in coverage

At a later fictional checkpoint, B receives an accepted correction with evidence and a new item D enters the population without review. Ready rises from 1 to 2, while eligible rises from 3 to 4. The new rate is 50 percent, not 66.7 percent. Report both the additional ready item and the new unfinished item.

If an old event arrives late, preserve the earlier published snapshot and issue a revision with the changed basis. Do not silently overwrite history as though the original report included evidence it had not received.

A Last updated label is not proof that a particular source change arrived. To test freshness, identify one exact source change and look for that identity/value in the report. If absent at 11:02 and present at 11:07, you know it is present by 11:07, not its exact arrival time or a universal seven-minute refresh guarantee.

Prepare different packets for different readers

A coordinator may need item IDs, current state, missing evidence and next action. A sponsor may need the ready/eligible total, the main risk and the decision required. Neither automatically needs raw event history, personal details or every internal note.

For the example, the coordinator packet can list A ready, B corrected and ready, C awaiting review, D newly added and awaiting review. The sponsor summary can say: “Two of four practice items are ready at this checkpoint. Two still need review; confirm the intended deadline and review capacity.” These are draft examples, not messages to send.

Content readiness, sharing authority and actual viewer access are separate. A correct calculation does not authorize disclosure. An approved audience does not prove the link works. Publishing a dashboard is not equivalent to granting the intended viewer the correct access level.

Verify the intended audience through supported access

Before any real share, confirm the exact object, version, data scope, recipients and allowed permission. Use the supported sharing route only when authorized, then have the intended permitted account open the intended object and verify the relevant content. Do not infer another person's access from an administrator's view.

If access is denied, retain the denial and request the approved correction. Do not substitute a public link, another person's account or a broader folder share. A copied screenshot can also disclose information, so it is not automatically a safe workaround.

End with an honest release decision

The reporting definition may be complete while native dataset, populated chart, filter, export, publish and recipient-access checks remain unavailable. State that distinction. A useful next action identifies the exact missing readiness layer and the evidence that would close it, rather than declaring the whole exercise finished or inventing a backend diagnosis.