Performance Analytics with Domain Seperation

[tonemking]

Hi,

My organizations supports many clients and we have multiple set up in one SN instnace. We have 3 domains and I am having trouble spinning up the PA tool. I tried following this vauge wiki Performance Analytics with Domain Separation - ServiceNow Wiki ;however, im getting no data on my dashboards. This is what I have tried.

-created the indicator source at the TOP level

•         specified the domain as Domain is "company"
  •         I get 121 matching records

-created the automated indicator at the TOP level

•         added the breakdowns, added indicator source

-created a new indicator group at the TOP levle

•         added the automated indicator as the indicator

-created data collector under the DOMAIN

•         added indicator to the Job
  • Ran the collector under the domain

All the other settings i did not mention were matched based off of SNs setup in the wiki and the results are 0 inserts.

Has anyone else attempted to use PA with a multiple domain instance?

[D van Heusden]

Hi Antone,

what version and patch are you running on? You should at least be on Eureka patch 10 or Fuji patch 2.

Let me know and we'll take it from there.

[tonemking]

Yes, I originally tried in Eureka patch10 and then we upgraded to Fuji patch4 shortly after. So i know we have the ability.

Best,

Antone

[D van Heusden]

Thanks Antone,

I'm going to have someone look at your post and we'll get back to you with a response tomorrow. Thanks for your patience.

[Robert Ninness · Accepted solution]

Hi Antone,

Firstly let me say thanks for sharing your experience with domain separation so far. We are actively developing solutions and tools to help customers with domain separation manage their Performance Analytics application. The documentation on the wiki needs to be updated, no doubt.

There are two recommended approaches for implementing Performance Analytics on a domain separated instance. These are:

1. Create a global set of Performance Analytics components (Indicators, breakdowns, sources etc) which every domain uses.

2. Create a separate set of Performance Analytics components for each individual domain.

There is a third hybrid option, which combines 1 and 2, but we recommend attempting this approach after one of the other options has been implemented successfully.

There are some limitations to both approaches:

1. Performance Analytics configuration cannot be tailored for an individual domain.

2. Potentially a lot of re-work if many domains share the same components.

Time for a bit of clarity on domain separation before I begin:

In my examples I will be using the domain tree from this page: Domain Separation - ServiceNow Wiki

When I say "up" the domain tree, I mean the direction towards the "SNC" or global domain. Parent domains are considered further "up" the tree from a child domain. Going from a child to a parent domain is considered going "up" the domain tree.

When I say "down" the domain tree, I mean the direction away from the "SNC" or global domain. Child domains are considered further "down" the tree from a parent domain. Going from a parent to a child domain is considered going "down" the domain tree.

Think of a domain structure as the "roots" rather than the branches of a tree.

Most of the Performance Analytics records are considered "Process Records". In the same way that a Business Rule in a parent domain can be overridden in a child domain, so too can Performance Analytics components. This is a trap! In most cases overriding Performance Analytics components from a parent domain in a child domain will break the configuration. This has to do with the way the platform handles references, and the way overrides hides the original record.

An example:

The "incidents.new" Indicator Sources is defined on the SNC domain. This Indicator Source modified by a user in SNC/US, a child domain of SNC, and an override record is created in SNC/US. When the user in SNC/US goes to view the "Number of new incidents" Indicator, he finds that the Indicator Source referenced by the "Number of new incidents" Indicator cannot be found. While the "incidents.new" Indicator Source is correctly overridden when viewing from a list of records, the platform does not replace references to the old Indicator Source when viewing the "Number of new incidents" Indicator. Just as the original Indicator Source is now hidden on a list by the override record, it is also hidden from the data collector. If the Indicator were to be used in a collection for SNC/US, an error would occur.

We are currently working on features which restrict creating override records for Performance Analytics records so that situations like this do not occur.

So why are Performance Analytics records "Process Records"? While Performance Analytics does not utilise the override feature of "Process Records", Performance Analytics takes advantage of the visibility rules of "Process Records" when it comes to domain separation.

What are "Process Records" anyway?

When it comes to domain separation there are two classes of record on the platform: "Data" and "Process".

Visibility of "Data Records" is top-down. Records stored in a domain are visible to domains higher up the tree (parent domains). This is great for data. A user in SNC/US can only see the incident records of his own domain, SNC/US, and of it's children: SNC/US/NY and SNC/US/CA. He cannot see records from the parent domain SNC.

On the other hand, visibility of "Process Records" is bottom-up. Records stored in a domain are visible to domains lower down in the tree (child domains). This is great for records which control processes e.g. Business Rules, Client Scripts.

A Business Rule defined on the incident table in domain SNC will be evaluated by an incident in domains: SNC, SNC/US, SNC/US/NY and SNC/US/CA. In this way a common set of rules for a process can be applied "down" the tree. A business rule defined on the incident table in domain SNC/US will be evaluated by an incident in domains: SNC/US, SNC/US/NY and SNC/US/CA but not in SNC. This allows for tailoring of process rules and logic for a specific domain, or branch of the domain tree.

With this distinction in mind, Performance Analytics allows the definition of a set of components in the global or a parent domain, to be used in child domains. This allows for approach 1, and to an extent 2.

PHEW! Now that all that is out of the way, let's get down to your specific issues.

Since you only have 3 domains, and from what I read your domain structure is fairly flat, I would go with option 1. It looks like based on the info on the Wiki you have started implementing option 2, which is fine, but would require you to re-create each Indicator on each of your domains. At the moment   it's not so bad because you only have 3 domains, but if you on-board more customers you may soon find that task or re-creating everything a chore.

The OOTB content, which comes with Performance Analytics for Incident Management, is loaded into the global domain. Because of the "Process" visibility rules mentioned above, you can use this content with any domain.

Let's call this Phase 1. What I would recommend is that you re-use this existing global configuration, un-modified, and start collecting for each of your domains.

Let's start with your first domain, because I don't know the names of your domains, I'll call this Domain A for now.

Make sure you are in the global domain.

Create a new Scheduled data collection job. This job needs to be in global, or override records will be created and we don't want that. Set the collection parameters similar to a historical job and relate the "Number of new incidents" Indicator to this job (use the OOTB record in the global domain).

To collect scores for Domain A, we need to select a Run As user from Domain A. This user does not have to be an administrator, I recommend using a "typical" user of the incident management process (not a requestor, an ITIL user). Set the Run As user in your new Job to be this user in Domain A.

Execute the job. It should now be collecting scores for Domain A. To check this go to /pa_scores_list.do and filter by scores on Domain A.

Now switch your domain from global to Domain A and open the detailed scorecard for the "Number of new incidents" Indicator. You should see that scores have been collected.

The domain of the Run As user of a Job defines which domain the job will execute against, not the domain of the job record.

The data collector also executes any ACL's and view business rules applicable to this user (that's why I recommend using a typical user) restricting access to particular records.

Switch back to the global domain, and do the same for your second and third domains, choosing a user from each domain to be the Run As user of the new job.

Switch between the domains and take a look at how the scores differ.

Phase 2:

Now that you have this basic setup configured, you can create new Indicators on the global domain and re-use them across your domains by relating the Indicator record to the three jobs.

The great thing about using the first approach is that there is no need to create separate widgets and dashboards for each domain. The existing OOTB global dashboards and widgets will display scores from the domain of the user viewing them. Switch between the domains and have a look at the Incident Management dashboard.

Phase 3:

Since you are on Fuji and have two levels of breakdown, I would also recommend creating a job for your company's domain. By creating a "domain" breakdown, you as an administrator can see the scores of all three domains at once and compare and analyse their performance together.

I hope all of this information helps. I will look at getting the wiki updated and perhaps also create a blog post for others to find.

TL;DR

The domain of the Run As user of a Job defines which domain the job will execute against, not the domain of the job record.

Regards,

~Robert