[object Object]

The executive dashboard refreshes for 40 seconds because someone built it on raw queries against incident. The analyst’s ad-hoc question takes a week because someone insisted on a PA indicator with breakdowns. Both teams are using the wrong tool, and the docs are too gentle about the distinction.

The actual decision rule

Standard tiles query live data at render time. PA queries pre-aggregated time-series data collected on a schedule. Use the live path when the user expects current data and the query is cheap. Use PA when the user expects trends over time and the query is expensive. Mixing them on the same dashboard is fine; using the wrong one for the load is not.

When live queries win

Operational dashboards for support managers — open incidents by priority right now, who is assigned, what is breaching SLA. The data must be current; trend over time is irrelevant. Filter aggressively, index the underlying table, and keep the result set under 5,000 rows. A well-tuned tile renders in under 2 seconds; a poorly-scoped one takes 30.

When PA wins

Anything looking back more than 24 hours, anything aggregating across more than 100,000 records, anything compared month-over-month. PA stores the result of yesterday’s expensive aggregation as a single score row. Loading 365 days of trend is reading 365 rows, not scanning 5 million records.

Daily incident volume by priority, last 12 months:
- Live: scans 1.5M rows on every render
- PA: reads 365 score rows from pa_scores

The dashboard composition pattern

A good executive dashboard mixes both. PA tiles for trends and breakdowns above the fold. Live tiles below the fold for current operational state. Never put a 30-day live aggregation on the top of an executive dashboard — it forces a full table scan on every page load by every viewer.

Conditional formatting and scoring

Scorecards (PA) support targets, breach thresholds, and trend arrows natively. Live tiles require manual conditional formatting that often gets lost in version control. If the metric has a target, use PA — the target is part of the data model, not a decoration on the chart.

Cost considerations

PA collection runs on the platform’s job queue and consumes database time. A poorly-designed indicator with high-cardinality breakdowns can take longer to collect than the live tile would take to render once. The break-even is roughly: if fewer than 50 people view the tile per day and it renders in under 5 seconds, leave it live. Above that threshold, convert to PA.

var gr = new GlideRecord('sys_report_run_log');
gr.addQuery('execution_time', '>', 5000);
gr.addQuery('view_count', '>', 50);
gr.query();

Common failure modes

Building a PA indicator for a metric that nobody actually checks weekly — the collection cost outweighs the value. Building a live tile that includes a 12-month trend chart — the chart drives the cost, not the operational data. Sharing a single dashboard across operational and executive audiences — split them; the priorities are different and the load patterns conflict.

What changed in 2026

Workspace dashboards in the Next Experience runtime now lazy-load tiles below the viewport, which mitigates the cost of mixing the two types. The first-paint penalty is smaller, but the underlying decision is unchanged. Older Service Portal dashboards render everything eagerly.

What to do this week: pull the top 20 entries by view_count from sys_report_run_log, identify ones running over 5 seconds, and shortlist them for PA conversion.

[object Object]
Share