Some PDIs are currently unavailable, and PDI actions are paused. View the latest updates here. Read More

“Too many elements to display” for breakdowns in Analytics Hub for Formula Indicator

Satya Harika
Tera Contributor

Hi Community,

We have created a custom formula indicator in Platform Analytics. When viewing the indicator in Analytics Hub, some breakdowns display the following message: Too many elements to display

The formula indicator is calculated using multiple contributing indicators, and the required breakdowns have been configured for the relevant indicators. However, the elements for certain breakdowns are not displayed due to the “Too many elements to display” message.

Could you please help clarify:

  • Is there a system property or configurable limit that controls the maximum number of breakdown elements displayed in Analytics Hub?
  • Can this limit be increased safely?
  • Is this message caused by a large number of elements associated with the breakdown?
  • What is the recommended approach for handling high-cardinality breakdowns in Platform Analytics?
  • Does this limitation affect only the Analytics Hub display, or could it also affect dashboard visualizations and interactive filtering?
    ServiceNow release: Zurich
    Module: Platform Analytics / Analytics Hub
    Indicator type: Formula Indicator

Thanks in advance.

1 ACCEPTED SOLUTION

Hi @Satya Harika,

 

The cap you're hitting is a UI rendering limit, not a data limit, and formula indicators make it worse because of how they're calculated. Per ServiceNow's own documentation, a Formula Indicator is never materialized: its score is computed at display time, whenever someone opens the dashboard, KPI Details, or Analytics Hub, and it never lands in pa_scores_l1, pa_scores_l2, or the legacy pa_scores table. So there's no stored dataset to query around the pivot's element cap, the pivot really is doing thousands of live calculations every time it renders.

The cleanest fix is to stop asking the formula to run live at all. If the percentage logic can be expressed as a script rather than a formula that references other indicators, convert it to a scripted Automated Indicator (a PA Script). Scripts run at collection time and their scores per breakdown element get written to pa_scores_l1/l2 like any other automated indicator, so once collected you can report on it with a standard List Report, which paginates and has no element ceiling the way the pivot does, or query it directly with GlideAggregate.

If the calculation genuinely has to stay a Formula Indicator because it references other live indicators, run it server-side instead of through the UI: use SNC.PAScorecard from a scheduled script, addParam the breakdown and the indicator, call query() once to walk every element in-process, and land the results in a table you own for List Report consumption. Either way, don't try to make the pivot show the full dataset, move the calculation off the render path entirely.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

View solution in original post

4 REPLIES 4

Vikram Reddy
Tera Guru

Hi @Satya Harika,

 

Yes, there's a specific property behind this: com.snc.pa.breakdown_element_cutoff, default value 50. It controls how many breakdown elements the Analytics Hub and KPI Details view will actually render for an indicator. It's a display-layer limit, not a data collection limit, so it's easy to confuse with the other property people usually hit first, com.snc.pa.dc.max_breakdown_elements_limit (default 10000), which decides how many distinct elements the data collector will even pull in for a breakdown source in the first place. Your data collection is almost certainly fine, since 10000 is a much higher bar. What's happening is the collected data has more than 50 distinct elements, and Analytics Hub refuses to draw all of them, hence the message.

Because this is a formula indicator, each contributing indicator collects its own breakdown data independently, and the formula rolls those scores up at read time. The cutoff still gets applied on the combined set when Analytics Hub renders it, so if any one contributing indicator's breakdown source (assignment group, CI, account, whatever you're slicing by) has a lot of distinct values, you'll see this on the formula indicator even though every underlying indicator collected correctly.

Can you raise the property safely? Yes, it's a straightforward system property change, no scripting involved. But treat it as a dial, not an off switch. Bumping it from 50 to a few hundred is generally fine. Pushing it into the thousands just to make the message disappear tends to slow the Analytics Hub UI down noticeably, because now it's rendering that many rows per widget on every load.

The more durable fix for genuinely high-cardinality breakdowns is to cut down what actually needs to render rather than raise the ceiling. An Element Filter (the classic example is "My Accounts" or "My Group") scopes the breakdown to a relevant subset for the user viewing it. A Breakdown Relationship does something similar contextually, so a second breakdown only shows elements related to whatever was picked in the first one, instead of the full unfiltered list. Both reduce the rendered element count without touching the underlying collected data at all.

On your last question: per its own description, this cutoff is scoped to Analytics Hub and KPI Details specifically. Dashboard breakdown widgets are governed by a related but separate element-count property for chart rendering, and interactive filtering pulls from whatever Element Filters or Breakdown Relationships you've defined rather than from this same cutoff directly. In practice though, a breakdown that's too wide for Analytics Hub is usually too wide for a dashboard widget to be useful anyway, so I'd apply the filter and relationship approach everywhere rather than treating Analytics Hub as a separate problem from your dashboards.

 

Thank you,
Vikram Karety
Octigo Solutions INC

Satya Harika
Tera Contributor

Thank you @Vikram Reddy for taking the time to provide such a detailed explanation. I really appreciate the insights and the suggestions regarding element filters and breakdown relationships.

However, I still have a question regarding our use case. We need to calculate and display a KPI percentage for each distinct breakdown element using a formula indicator. Since there are thousands of distinct elements, filtering them may not meet the requirement, as we need the KPI results across the complete dataset.

I understand that displaying thousands of elements along with their respective percentages in a pivot visualization may not be practical. Is there any recommended alternative approach to achieve this requirement?

Hi @Satya Harika,

 

The cap you're hitting is a UI rendering limit, not a data limit, and formula indicators make it worse because of how they're calculated. Per ServiceNow's own documentation, a Formula Indicator is never materialized: its score is computed at display time, whenever someone opens the dashboard, KPI Details, or Analytics Hub, and it never lands in pa_scores_l1, pa_scores_l2, or the legacy pa_scores table. So there's no stored dataset to query around the pivot's element cap, the pivot really is doing thousands of live calculations every time it renders.

The cleanest fix is to stop asking the formula to run live at all. If the percentage logic can be expressed as a script rather than a formula that references other indicators, convert it to a scripted Automated Indicator (a PA Script). Scripts run at collection time and their scores per breakdown element get written to pa_scores_l1/l2 like any other automated indicator, so once collected you can report on it with a standard List Report, which paginates and has no element ceiling the way the pivot does, or query it directly with GlideAggregate.

If the calculation genuinely has to stay a Formula Indicator because it references other live indicators, run it server-side instead of through the UI: use SNC.PAScorecard from a scheduled script, addParam the breakdown and the indicator, call query() once to walk every element in-process, and land the results in a table you own for List Report consumption. Either way, don't try to make the pivot show the full dataset, move the calculation off the render path entirely.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

Thanks @Vikram Reddy , this helps me a lot