Questions on Platform Analytics best practices

[kim-lindgren]

Hi all,

I have a couple of questions on PA best practices as my organization is going to try to define how to work with PA and what to avoid.

1. Creating breakdowns and breakdown sources. The suggestion here is that we do not allow the creation of several breakdown and breakdown sources for the same things in the global scope, e.g. Assignment group, because it creates too many different choices.

However, in the docs you can read:

Multiple breakdowns can use the same breakdown source. For example, instead of seeing ALL assignment groups for the Number of Open Changes indicator, you can limit the element list to just those groups that are part of the change process by configuring the Breakdown Source.

This formulation isn't clear - do they actually mean that the configuration should be done on the breakdown or on the breakdown source? If they mean the breakdown source, the problem is that dashboard filters cannot apply values from several breakdown sources at once, increasing the risk for conflicts. So we are leaning towards disallowing new breakdown sources in a scope completely, and instead recommending filters to be applied on the breakdown ("Default elements filter") or on the dashboard directly. The problem is that someone could still point to the docs and say "this is not a best practice".

2. PA indicators in data collection daily jobs should only be bundled together if they have the same indicator source - do you agree with this or not? I am pretty sure that this was brought up in a PA course I took and suggested as a best practice to limit the number of queries against the database. But now I can't find it, instead the docs simply says:

Data collection jobs query the database once for each indicator source. Thus, all indicators that use the same indicator source get data from the same point in time. 

Would you say that it is a best practice or not? Or would you recommend some other standard for grouping indicators together in a data collection job?

I understand that not all of this is set in stone, but I would love to hear some recommendations based on other people's experiences.

Regards,

Kim

[sachinchaudhary]

HI, @kim-lindgren 

You have raised two excellent, highly strategic questions. Your architectural instincts are completely correct, and your proposed governance standards align perfectly with enterprise best practices despite how the out-of-the-box documentation is phrased.

Here is how you can address both points with your team using the official framework:

1. Breakdown Sources vs. Elements Filters

   Your team’s leaning is 100% correct. You should absolutely restrict the creation of duplicate Breakdown Sources for the same underlying facts table (e.g. sys_user_group).

   • Why the Docs are confusing: The phrase in the ServiceNow Breakdown Sources Documentation stating that you can limit the list "by configuring the Breakdown Source" refers to creating a unique, filtered breakdown source record. While technically valid, doing this creates severe user experience bottlenecks on Interactive Dashboards / Next Experience Filters.

   • Conflict: Dashboard filters target a specific breakdown source. If different widgets on the same dashboard use different breakdown sources for "Assignment Group," your unified dashboard filters will fail to cross-apply uniformly.

   • Best Practice: Standardize on one global Breakdown Source per table. To restrict elements for specific indicators or processes, leverage Default Elements Filters on the Breakdown record itself or filter directly inside your dashboard/widget configuration. This keeps your data model clean and ensures dashboard filters remain reliable.

2. Indicator Bundling in Data Collection Jobs

   To answer directly: No, you do not need to create separate scheduled jobs for every unique indicator source. Your recollection is accurate regarding query minimization, but it actually points toward bundling them together.

   • How the collection engine works: As highlighted in the ServiceNow Indicator Sources Documentation, the collection engine automatically groups indicators by their source. When a single job runs, it optimizes database overhead by executing exactly one query per indicator source, bringing that record batch into memory, and then running all related indicators against that single cached state.

   • Best Practice: Bundle your daily indicators together into broader, process-based jobs (e.g., "ITSM Daily Collection" or "HR Daily Collection") rather than splitting them into dozens of separate job schedules.

   • Why split them? You should only isolate an indicator into its own job if it requires a different execution frequency (e.g., Monthly vs. Daily), belongs to a strict scoped application access barrier, or runs a complex script that takes hours and needs to be isolated, so it doesn't delay standard process collections.

Summary Action Item for Your Framework:
You can confidently defend your framework by pointing out that keeping breakdown sources unified protects Dashboard Filter integrity, while bundling daily jobs protects Platform Performance by cutting sequential connection overhead.

Hope this helps you finalize your organization's PA governance blueprint!