An overview of how Performance Analytics complies with Domain Separation
The PA Scores table, the source of the data for widgets and scorecards, is a domain separated table. What determines which domain a Score is recorded against depends on the configuration of the Data Collector Job, NOT the domain of the source records.When a Data Collector Job runs, the visibility of that job is determined by the Run As user. The roles, entitlements and domain of the Run As user control the visibility of records targeted by the Source of each Indicator in the job. What this means for domain separation is that in order to collect scores for a particular domain, the Run As user for the job, needs to be a user from that domain.
There are two ways which Performance Analytics can be configured to support Domain Separated instances of ServiceNow.
- Global configuration, accessible to all domains, with jobs configured to collect per domain.
- Domain specific configuration, accessible only to a particular domain, with a job configured to collect for this domain.
Option 1: Global configuration
This option is recommended as a way of providing a single set of dashboards to multiple domains.
When the Performance Analytics plugin is first activated a number of content packs are also available. These content packs provide a best practice approach to Incident, Problem, Change and SLA management. The content packs place the configuration records (indicators, breakdown, source, dashboard to name a few) in the "global" domain. Because these are global records users in a domain given the pa_viewer role or higher will be able to access the dashboards and scorecards without any further configuration needed. To start filling these dashboards with data, a new Data Collector Job will need to be created and scheduled for each domain you wish to collect on (you may also wish to run a historical collection).
Scores collected by these jobs will be recorded against the domain of the Run As user, and when a user views a dashboard, only those scores belonging to the same domain will be used as data for the widgets and scorecards.
NOTE: Using this method it is not recommended to give pa_admin access to users belonging to a domain. If a user in a domain modifies a PA record in the global domain, a new override record will be created (similar to how business rules work) this may cause unexpected results for the user as relationships to PA Jobs and sources are NOT re-created.
Option 2: Individual PA configuration for a domain
This option is recommended for domain users who require pa_admin access to configure their own domain specific PA components
If a different configuration is needed for a specific domain, the records will need to be re-created within that domain. For example, if a condition needs to be added to the Indicator Source for the "Number of new incidents" Indicator for a specific domain, then the Indicator and Indicator source need to be re-created for that domain. If the Indicator also requires breakdowns, those breakdowns will also need to be re-created for that domain.
After all the configuration has be set up, a new data collector job needs to be created and the new indicators linked to the job.
NOTE: Records of different domains do NOT work together, e.g. an Collecting an Indicator on domain A which has a source of domain B will not work. The same goes for Indicator-Breakdown relationships. Each component that is required for an individual domain should be re-created for that domain.
NOTE: Option 1 and Option 2 can be used together, although it is not recommended to provide users outside the global domain with pa_admin role if Option 1 is being used as they can modify these records and potentially break the Configuration of option 1 for the other domains.