[object Object]

A stakeholder asked for “incidents broken down by everything” and the analyst did exactly that. Six months later the daily collection job is taking eleven hours, the indicator score table has 40 million rows, and the dashboard takes 90 seconds to render the first tile. Performance Analytics breakdowns are the most powerful and most abused part of the platform.

Cardinality is a budget, not a free dimension

Each breakdown multiplies the score row count by the number of distinct values. Three breakdowns on a daily indicator with cardinalities of 10, 50, and 200 produce 100,000 rows per day before time-series accumulation. Treat the product of cardinalities as a hard budget; anything over 50,000 daily rows needs justification before it ships.

daily_rows = unique(dim1) * unique(dim2) * unique(dim3) * snapshots_per_day
target: < 50k for routine indicators, < 250k for executive ones

Pick dimensions that drive decisions

A breakdown only matters if someone changes a decision based on the slice. “Incidents by assigned_to” with 4,000 fulfillers produces a chart no human reads. “Incidents by support group” with 60 groups drives staffing conversations. Always ask which decision the breakdown enables — if there is no answer, do not build it.

Use breakdown sources, not raw fields

Direct breakdowns on a dynamic field (assignment_group) are evaluated at collection time and cannot be filtered later. Define a Breakdown Source on the source table with a clean name and an active filter. The same source can feed multiple indicators, scores are reusable, and you can retire a value from the source without rebuilding history.

Element groupings tame the long tail

A 200-value breakdown becomes useful with element grouping. Define five buckets — Tier 1 (top 10), Tier 2 (next 20), Long Tail (rest), Unassigned, Other. The dashboard shows tiers; analysts drill into Tier 1 specifics. The score table still holds the granular data, but day-to-day rendering uses the grouping.

Domain separation multiplies the cost

In a multi-domain instance, the engine evaluates breakdowns per domain. A 50-domain MSP with what looks like a modest indicator has 50x the score volume. Use domain-aware breakdown sources or accept that some indicators run per-domain on a slower schedule (weekly instead of daily) for the small domains.

Collection schedule alignment

Breakdowns inherit the indicator’s collection schedule. If the parent indicator collects hourly, every breakdown collects hourly. Confirm the business need — most breakdowns are useful daily and pointless hourly. Splitting indicators by frequency is cheaper than collecting everything at the highest cadence.

// In a scheduled script: skip a breakdown when source filter returns nothing
var br = new SNC.PABreakdown('breakdown_source_sys_id');
if (br.getCount() === 0) return;
br.collect();

Common Failure Modes

A breakdown with null value rows that nobody noticed — filter valueIS NOT NULL in the source. A breakdown that includes archived records — restrict the source to current data and let history live in archived tables. A breakdown whose values change names (group renames) — use sys_id as the breakdown key and let display name be derived.

Implementation Sequence

Start with the executive dashboard and work backward. Identify the three to five charts that drive monthly conversations, define the indicators and breakdowns to support exactly those, and resist adding more until someone asks. Indicators are easy to add and painful to remove once a dashboard depends on them.

What to do this week: query pa_scores grouped by indicator_id and count rows per indicator — anything over 5 million rows for routine reporting is your cleanup candidate.

[object Object]
Share