Domain separation in CMDB Health

Overview

Domain separation is supported in this application. Not all ServiceNow applications support domain separation; some include limitations on the data and administrative settings that can be domain separated. To learn more, see Application support for domain separation.

CMDB dashboards should be set up with their own set of rules to best accommodate how the user needs them. CMDB dashboard jobs adhere to those rules to produce reports. These are covered in separate sections below.

How domain separation works in CMDB Health

For dashboards to be the most effective, users should configure the dashboard accordingly. This is done by setting up the orphan, staleness, and inclusion rules to meet their needs, and which then affect the reports displayed on the dashboard.

The settings and metrics define different aspects of each application because each domain can be configured differently. These rules are set up in addition to those that are included in the base system. There are different types of owners for different CIs; each domain has its own set of rules.

Health Preferences

Configure these preferences during setup:

1. Global system properties that control CMDB Health – System properties are not domain separated. To learn more see CMDB health system properties.
2. CMDB Health Dashboard Jobs – There is a dashboard job for each major KPI, such as Completeness. That job finds the health of the CIs across all the enabled domains. There is only one job run for all domains and jobs themselves are not domain separated. To learn more see Enable and configure a CMDB Health Dashboard job

   Users can define the frequency with which they want to run jobs; the report runs for all the domains. The more domains included in the job, the longer the job runs.

3. Health Metrics – These selections are domain-separated and adhere to the established “system overrides” logic of domain separation. Changes are made according to the domain for which the user is logged in. Base system values are defined at the global domain. The overriding domain logic means these values apply for all domains. If users want different values for a domain, they must be logged in to a specific domain and change the property from there. The new property setting applies only to that domain and any domain that inherits this domain. To learn more see Health Metrics.
   Note: Regarding the Completeness, Compliance, and Correctness KPIs: Users can disable this KPI if they don’t want to see that as part of the dashboard score. All these settings are domain-separated and the user can define specific properties for the domain.
   1. Weighted averages – These settings can affect all or part of the metrics in Completeness, Compliance, Correctness, and Relationship. They can be set differently for different domains.
   2. Active – This setting is the most important because it affects how long the jobs run. The more domains with flags set to Active, the longer the jobs take. It’s best to select only those domains you wish to be Active and render the rest Active = false. You can set this in Health Preferences. The default settings for global domain are set to Active = true, but you can modify or disable specific domains the user wants to see in the dashboard. Users should consider the domain hierarchy when changing these values. If there is a large number of domains (>100) the job can take a very long time. To mitigate this, set Active to False for all the root domains, thereby disabling all the other domains in the hierarchy. If there is a rule at the top, all child domains inherit that rule.
   3. Failure Threshold, Create Task, Task Assignee Group – All these settings can be set differently for different domains depending on what is needed in each domain.
   4. Exceptions – For Relationship metrics (relationship, duplicate relations, orphan relations, stale relations) the failure threshold setting is not domain separated. The Failure Threshold for the global domain is applied to all domains. For example, even if users were to override the Failure Threshold for a domain, the global domain setting for Threshold is still applied.
   5. Troubleshooting / Implementation detail – These settings are stored in the cmdb_health_metric_pref table, which is domain separated.

Health Rules

Health rules settings are addressed here:

• Required
• Recommended
• Orphan
• Staleness

Most of the CMDB Health Rules are domain separated and provided by the users. Users can define different rules for different domains by logging in to each domain and adding/overriding rules in the CI Class Manager.

These are the rules for the different metrics:

1. Completeness
   1. Required fields – These are based on the class schema defined in the platform’s System dictionary and is fixed for all domains. These cannot be changed.
   2. Recommended fields – These are domain separated. The table used is cmdb_recommended_fields, which is domain separated. The user can set these up for different domains.
2. Correctness
   1. Duplicates – Duplicates are based on Identification rules, which are not domain separated, so the same rules apply to all domains.
   2. Orphan – Orphan rules are domain separated; there are different orphan rules for different domains. The table used is cmdb_health_orphan_rule and is domain separated.
   3. Staleness – Staleness rules are domain separated. The table used is cmdb_health_staleness_rule. The base system rule (60 days) is set for global domain so is inherited by all domains as the default rule.
3. Compliance
   1. Audit – Audit scores are based on the desired state or scripted audits defined in the compliance module by the user.

      Audits themselves are domain separated. When audit score evaluation is enabled for a domain, scores become based only on the audits visible in that domain.

Health Dashboards (CMDB View/ Service View / Group View)

If a user is logged into a domain and views a health dashboard:

1. Only scores for enabled metrics in that domain display (based on the Health Preferences Active flag as discussed above).
2. All scores are based on CIs that are visible from the specific domain. (These are regular domain visibility rules: From that domain you can see CIs in global domain, the specific domain, any child domain of that domain or any domain that gets directly or indirectly contained by that domain.)
3. The dashboard view is based on domain rules defined in domain mapping, as opposed to those provided by the logged-in user. This view overrides any additional domain visibility rules that a logged-in user might have. The admin sets the basic rules, but does not set each individual domain. The admin can give specific users or user groups additional visibility to other domains and the dashboard still does not change. The dashboard strictly follows the domain rules mentioned above, based on the domain hierarchy for the domain in which the user is logged in.
4. As explained in the Health Preferences section, users can define different preference values for any domain which impact the scores reported in the dashboard. Preferences that can impact scores include Weighted Averages, Failure Threshold, and Active.
5. As explained in the CMDB Health Rules section, the scores reported for the metrics are based on the health rules defined for them (staleness, orphan, recommended, audit, and inclusion rules) which can be defined differently for a specific domain (in the CI Class Manager). Only the required metric and duplicate metric are based on rules that apply in all domains.
6. Service View/ Group View – These reports also largely follow the above points. Typically, these views differ from various views/filters for the Health Report. One is based off business rules, the other is based off CMDB Health groups.