From software problem to a clear next step.
Choose a topic and what you need to do next. Add a search phrase to find a specific problem.
Browse 20 topics
Explore the playbooks
1500 guides · Page 31 of 60
-
Triage Report Filter to Card Mapping
Scope a filter-to-card issue by comparing selected controls, card population, measure scope, and nearby visual behavior.
-
Prioritize a Filter-to-Card Mapping Fix
Rank filter-to-card work by decision consequence, affected headline measures, and evidence that propagation differs from the report contract.
-
Investigate Report Filter to Card Mapping
Trace a selected filter from control state to headline card population and measure to locate the first propagation divergence.
-
Verify Report Filters Reach the Right Cards
Check that intended report filters change headline cards, excluded controls stay independent, and card labels expose their population.
-
Learn From Repeated Filter-to-Card Confusion
Turn recurring headline-card filter mistakes into propagation fixtures, scope definitions, and review cues that keep report controls honest.
-
Triage a drilldown that changes the report question
Trace the clicked value and resulting child scope to separate valid drilldown behavior from an unintended filter, grouping, or date change.
-
Prioritize drilldown scope defects by user consequence
Rank drilldown scope issues by the decisions they can distort, the report surfaces affected, and the clarity of the expected parent-to-child relationship.
-
Investigate a drilldown with a reproducible scope brief
Build an evidence-backed drilldown brief that compares parent and child predicates, grouping, dates, and population boundaries using one repeatable click path.
-
Verify drilldown scope across parent and detail views
Check inherited filters, grouping, dates, labels, and totals across representative drilldowns so the child view answers its documented question.
-
Learn from repeated drilldown scope confusion
Turn recurring drilldown questions into explicit scope contracts, fixtures, and review cues that keep parent and detail views aligned.
-
Triage a report that may be showing stale cached data
Separate a delayed report result from a source lag, period mismatch, or interpretation error by recording freshness context beside the disputed value.
-
Prioritize report freshness issues by decision timing
Rank freshness concerns by decision deadline, boundary visibility, affected reports, and cost of acting on a result users believe is current.
-
Investigate report cache freshness with timestamp evidence
Reconstruct report, source, and display timestamps to explain whether cached material excludes expected events or only appears late to the reader.
-
Verify report freshness labels against data boundaries
Check as-of labels, selected periods, comparison values, and export context so readers can tell what report data is included and when it was prepared.
-
Learn from recurring report freshness discrepancies
Turn repeated freshness questions into timestamp conventions, boundary fixtures, and ownership cues that make delayed report material easier to interpret.
-
Triage report totals that may be inflated by join fanout
Trace the report's row grain and join relationships to separate legitimate repeated detail from multiplication that changes an aggregate.
-
Prioritize join fanout issues by decision impact
Rank join fanout concerns by distorted measures, dependent decisions, report reach, and whether the intended grain is documented well enough to act.
-
Investigate report join fanout with grain evidence
Build a reproducible fanout brief that compares base rows, joined rows, aggregation stages, and resulting measures at the report's stated grain.
-
Verify report measures across one-to-many joins
Check totals, grouped values, empty children, detail rows, and exports against an explicit grain contract so join fanout cannot silently alter report meaning.
-
Learn from recurring join fanout findings
Turn repeated fanout findings into grain contracts, cardinality fixtures, and review prompts for report measures built across one-to-many relationships.
-
Triage a distinct count that changes across report views
Compare identity fields, grouping scope, filters, and join paths to find why a distinct-count measure differs without assuming every difference is an error.
-
Prioritize distinct-count discrepancies by decision risk
Rank distinct-count issues by the decisions they influence, identity ambiguity, affected report surfaces, and the cost of comparing incompatible populations.
-
Investigate distinct-count logic with identity fixtures
Build a distinct-count brief with repeated identifiers, nulls, group overlap, filters, and joins to locate the first semantic divergence.
-
Verify distinct counts across filters, joins, and groups
Check unique-entity counts with repeated rows, overlapping groups, missing identifiers, period boundaries, and exports against the report's stated identity rule.
-
Learn from recurring distinct-count interpretation errors
Turn recurring distinct-count questions into identity definitions, overlap fixtures, and report wording that keeps unique populations comparable.