This is an overview of domain separation as it pertains to CMDB Health. Domain
separation enables you to separate data, processes, and administrative tasks into logical
groupings called domains. You can then control several aspects of this separation, including
which users can see and access data.
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.
Note: Domain separation is on by default, but each domain can be configured as needed.
Configure these preferences during setup:
- Global system properties that control CMDB Health – System properties are not domain
separated. To learn more see CMDB health system properties.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
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:
- Completeness
- 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.
- 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.
- Correctness
- Duplicates – Duplicates are based on Identification rules, which are not domain
separated, so the same rules apply to all domains.
- 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.
- 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.
- Compliance
- 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.
Note: Health Inclusion Rules are also domain separated. The table used is
cmdb_health_config
, which is domain separated.
Health Dashboards (CMDB View/ Service View / Group View)
If a user is logged into a domain and views a health dashboard:
- Only scores for enabled metrics in that domain display (based on the Health Preferences
Active flag as discussed above).
- 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.)
- 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.
- 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.
- 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.
- 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.