Chapter 8.6 Introducing Domain Separation PDF

01/03/2017 IntroducingDomainSeparation
Introducing Domain Separation
Domain Separation is designed to control what ful llers can see and do. ServiceNow
applications have been typically designed so that a ful ller has access to all the tasks in a
particular application and the application works consistently for each person. Domain
separation tags con guration and data so that the platform can choose what is relevant
for a particular user at the appropriate time.
The design for domain separation is focused on the needs of Managed Service Providers
(MSPs). These use ServiceNow for helpdesk and other services and sell their capabilities
to their customers. This means that an MSP can provide a large call center, enjoying
economies of scale, providing ful llers who input incidents for multiple companies - all in a
single instance.
While the instance should be con gured with the MSP's standard processes as a baseline,
each customer of the MSP may have speci c con guration requirements. Additionally, the
MSP's customers may want to have their own users to log in to the instance and work on
tasks. Of course, the MSP would only want the users to see the data that they should.
Therefore, Domain Separation helps achieve three speci c goals:
Process separation: In process separation, conguration such as Business

Rules or Client Scripts are selectively applied. A customer of an MSP may have
different assignment rules to another.
https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781786465955/8/ch08lvl1sec79/Introducing+Domain+Separation 1/28
UI separation: In UI separation, different domains may have different forms

and related lists, as well as different options in choice lists. The latter ability is
very handy to have different categorization options per MSP customer.
Note
Process and UI separation are both considered as conguration. When I refer to
conguration separation, I'm referring to both process and UI separation.
Data separation: In data separation, records such as other users, tasks, or

locations are only available to the right people. This means that a user that works
for an MSP's customer, perhaps even one with fulller rights such as the itil
role, would only see records for their company.
Note
The difference between conguration and data is discussed in much more detail
in Chapter 10, Packaging with Applications, Update Sets, and Upgrades.
Dening a domain
A domain is simply a logical grouping of con guration and data. If a certain set of people
need to have a con guration that applies just to them or they want to be restricted from
seeing certain records, then they may need a domain.
Note
As we discover though, Domain Separation is not a cure-all. Do not assume that this
functionality will solve easy use-case regarding to separation.
When you use the Domain Separation plugin, you need a table that provides the domains.
This table must have a reference eld that refers to itself-the parent eld. Most of the
time, a dedicated table called Domain [ domain ] is used, but others, such as the Group
table, are occasionally used.
Tip
The Domain table is created with the DomainExtensionsInstaller plugin. It
also provides typical congurations and best practices.
In turn, every data or con guration record is associated with a domain. When the domain
support plugin is turned on, it creates a reference eld called Domain [ sys_domain ] on
many hundreds of tables. Some tables already have the eld available, and once the plugin
is installed, it is 'activated'. This allows items, such as an assignment rule, to be associated
with a particular domain. Users are also associated with a domain.
Applying Domain Separation

At the most simple level, Domain Separation compares the domain of the user or the
record with that of the data or con guration.
If the domain of the logged-in user is the same as the domain of the data, it can be seen, as
shown in the following gure:
If the domain of the record is the same as the domain of the con guration, it is applied, as
shown in the following gure:
Tip
At its most raw level, domain separation adds a WHERE clause to a database
query. A highly simplied example is when a query for user records is modied to
look like this:
SELECT*FROMsys_userWHEREsys_domain=<domainofloggedinuser>
Organizing domains
A domain is typically related to another domain in a parent-child relationship. The domain

hierarchy is the backbone of domain separation since it can have a great impact on how
con guration is applied or what data can be seen. How the hierarchy is applied depends
upon which item is being considered:
The user's domain is used when viewing data. Any records that are associated
with that domain or lower are visible.
The record's domain is used when applying conguration. Any conguration

that is associated with that domain or higher is applied.
Introducing global
Not all records in the instance will be tagged with a domain. Some tables, such as those
that store properties and Script Includes, do not have a Domain eld. These items will be
processed regardless of what domain is in use. For tables that are separated by domain,
such as Business Rules, it is possible for the Domain eld to be empty. In both these
situations, the item is considered to be global.
Global is technically not a domain. Instead, it is the absence of a domain. If a record is

global (ie, the Domain eld is empty), then it is outside of domain processing. This means
that if a Business Rule has no domain, it is always run. If a group has no domain, everyone
can see it, regardless of what domain the user is in.
Tip
Be careful to differentiate between global when working with domains as opposed to
applications. They are certainly not the same thing!
If a user is not associated with a domain, they will again be outside of domain processing-
they will see everything. If a record is global, then only global con guration will be applied
to it.
Understanding domain inheritance

The following diagram shows a simple domain hierarchy. Domain A is the parent of both
Domain B and Domain C. We'll use this structure to discover how inheritance works:
The table lists how the platform uses the domain structure to apply con guration and
control data visibility:
Domain being considered Conguration applied Data visibility
None (so global) Global Global, Domains A, B, and C
A Global, Domain A Global, Domains A, B, and C
B Global, Domains A and B Global, Domain B
C Global, Domains A and C Global, Domain C
The rules have the following results:
Since domains B and C are siblings, they have no impact on each other
Global data is always visible, and global conguration is always applied
A user in domain A will be able to see data associated with global and domains
A, B, and C
A record in domain A will only be affected by congurations that are

associated with domain A (and global)
Users in domain B will only see data that is associated with domain B (and
global)
Records in domain B will use conguration from both domains A and B (and
global)
Turning on Domain Separation

Turning on Domain Separation

In order to use Domain Separation, you must install the domain support plugin. I
recommend starting with the Domain Extensions Installer process pack, which bundles
the plugin together with helpful scripts, demo data, and a sensible default con guration.
Note
Once installed, Domain Separation cannot be removed from an instance. The
functionality can be disabled, but the additional elds and options will still be
available. Therefore, install this on a noncritical test instance only.
The Domain Separation plugins cannot be installed by an admin on an instance, due to the
substantial impact it has on an instance. (Only activate it on a disposable, sandbox-style
instance that you are happy to clone over!) It may also affect licensing costs. How you
activate it depends on the instance type:
If you wish to activate it on a standard ServiceNow instance, log into the Hi

Customer Support system, and using the Manage Instance dashboard, request
the DomainExtensionsInstaller plugin. Customer Support will then evaluate
your request.
For a developer instance, log into the Developer portal, and select to manage
your instance. Using the Action menu, choose to activate a plugin, and then select
the DomainSupportDomainExtensionsInstaller plugin.
Looking at Domain Separation
Once the plugin is installed, follow these steps to review the standard functionality and
examples:
1. Firstly, lets make selecting a domain much easier. As your normal admin user,
click the Settings menu top right, and in the General options, activate Show
domain picker in header. This will give you a drop-down selection that sits next
to your application picker.
2. The Domain Extensions plugin contains a few example domains that are useful
to understand how the system works. To see a list of these domains, navigate to
Domain Admin > Domains. You can see that the eight example domains are
related to one-another via the Parent eld.
3. To see a graphical representation of this, navigate to Domain Admin > Domain

Map, as per the screenshot below. Unfortunately, this has been rotated to how it
is typically visualized, meaning the top parent domain is on the left, but it still
provides a good idea of how the domains are related to one another.
Most often, domains are related to companies. In the example data, ACME, Oceanic
Airlines, and Initech all buy services from the MSP. Cisco supports the MSP as a vendor.
There are records in the both Domain table and the Company table to represent this.
The DomainExtensionsInstaller plugin contains scripts that automatically set the

domain when the Company eld is populated on a task or a user record. If a domain
cannot be found, a business rule will move the tasks into a domain called Default. This
ensures that the tasks don't get put into the global domain by accident and are thus visible
to everyone.
Exploring domain visibility
The best way to understand how Domain Separation works is see it in action:
1. Navigate to User Administration > Users to show all the users in the system.
Click the Personalize List icon, and add Domain eld into the Selected list. Click
OK once done. The list should look like the screenshot below:
2. Use the Domain Picker to select different domains. As you do so, the records
that are shown in the list will change. It is easiest to see the differences if you
sort or group by the Domain eld.
3. If you pick the Initech domain, you will be subject to Initech's data visibility rules.
This means that you will see the data tagged with no domain (that is, global), TOP,
and Initech. In contrast, if you switch to the Cisco domain, you will see Cisco's
users and not Initech's.
Tip
Domains are usually represented with their hierarchical name in the interface.
Since Initech is a child of TOP, it will be titled TOP/Initech. Note that once you
have switched domains, there is no indication that you are not seeing the full
dataset, beyond the domain picker. All queries, lters, and actions will be applied
only to the limited list.
Understanding Delegated Administration
When discussing domain separation, the product documentation talks about delegated
administration. Many think that this allows a user to have a "sub-admin" capability: the
ability of a user to change a part of the con guration in a certain domain. However, this is
not the case.
Tip
Delegated Development uses scoped applications to give a similar effect. This
capability is discussed in Chapter 2, Developing Custom Applications.
Delegated Administration simply means that a con guration can be applied to a particular
domain. In the example dataset, the con guration could be applied to the Initech domain,
thus ensuring that it is only applied to Initech (and any subsequent children).
Note
A user with the admin role has control over the whole instance. The truth of this
statement does not change with Domain Separation. An admin can choose which
domain they are currently associated with and control the domain conguration and
data it is associated with.
Overriding conguration
Con guration from a higher domain may be considered as a template. It will be applied to
domains that are lower in the hierarchy unless it is overridden. In a domain-separated
instance, all con guration will have a eld called Overrides [ sys_overrides ] in
addition to Domain [ sys_domain ]. The Overrides eld is a reference eld to the table
on which it is created. For example, the Overrides eld on the Business Rule table will
point to the Business Rule table.
Tip
The denition of a conguration in a domain-separated instance may be considered
as a table that has both the Domain and Overrides elds.
When altering con guration that is inherited from a higher domain, the platform will
automatically use this eld to create copies. This ensures the right domain receives the
right version.
Displaying different messages for different domains

To show how a con guration can be overridden at a particular domain, let's create a
simple Business Rule and then override it at a lower domain level:
1. Firstly, use the Domain Picker to switch to the TOP domain. It is good practice
to put all your con guration into a domain rather than use global.
2. Then, navigate to System De nition > Business Rules, click New, and ll out the
form using the following values. Save the record once done.
Name: Displaymessage(TOP)
Table: User[sys_user]
Advanced: <ticked>
When: display
Add message: <ticked> (In the Actions tab)
Message: TOPdomain
3. Change into the TOP/Initech domain using the Domain Picker. Then, in the
same Business Rule that you just created, and change the values in the following
items:
Name: Displaymessage(Initech)
Message: Initechdomain
4. Ensure that you click on the Update (or Save) button to update the current
record (do not use Insert and Stay).
A message will appear letting you know that the platform hasn't actually
overwritten the Business Rule, but it has created a copy and set the Overrides
eld:
5. To see what has happened, switch to global in the Domain Picker and navigate to
System De nition > Business Rules table. Then, scroll to the bottom of the list
and click Expand Domain Scope under Related Links. Also add the Domain and
Overrides elds using Personalize List to be to see what has happened.
The Domain eld speci es which domain will run the script. Any domain
underneath TOP will run the Displaymessage(TOP) business rule, except
for records associated with the Initech domain. It has its own Business Rule that
will run instead and speci es this with the Overrides eld.
6. To try this out, navigate to the User table and open up a variety of users. The
message that will appear will depend on the domain of the user:
When you view user records in the Global domain (such as JoeEmployee in
the following screenshot) you will not receive a message:
User records in the Initech domain (such as InitechEmployee in the

following screenshot) will show Initech Domain due to the speci c business rule
associated with this domain:
User records in the ACME domain (such as ACMEEmployee in the following

screenshot) will show TOP Domain since they inherit the con guration from the
TOP domain:
Creating more domain relationships
In addition to hierarchical relationships, a domain can contain other domains. This can be
accomplished by using a related list on the Domains form and populating the Contained
Domains [ domain_contains ] table.
When containing a domain, you indicate that you want to see all the data that the domain
can. Since data ows up, you effectively specify another parent.
In the example data, the MSP domain contains TOP. This means that a user in the MSP
domain can see all of the data that TOP can see, and since TOP is at the top of the
hierarchy, this means that the user can see everything. Even though MSP is a sibling of
Initech, because MSP contains Initech's parent, which is TOP, MSP can see all of Initech's
data. Unfortunately, the instance doesn't represent this on the domain map, but if it did, it
might look like this:
One reason to do this is to allow tasks associated with the MSP domain to have special
domain-speci c processing rules, but have the users see other domains. They can work on
Initech tasks, while Initech users cannot see them.
Tip
Another way to access more data is through a visibility group: a specic group can
be given the privilege to see another domain's data.
To try this out, switch to the MSP domain, where you can see every user-even those in a
sibling domain.
Using Domain Separation appropriately

Domain Separation is sometimes seen as a magic x for separation needs. Although it is a

powerful feature, it isn't always the right choice. It is a complex technology, and there are
simpler alternatives to each of its features:
For UI separation, you can use views with view rules and dependent elds to
drive choice lists
For process separation, you can use conditions on business rules and other
functionality, such as assignment rules, and add conditions into client scripts
For data separation, you can use access controls and before query Business
Rules
Tip
It may also be more appropriate to create a custom app for a particular situation,
perhaps by using table inheritance. For instance, consider creating a dedicated app
for the grounds keeping team instead of trying to break up a hotel room maintenance
system. Two tables are much easier to deal with than one that is domain separated.
However, for MSPs, it provides a great way to provide a global template that allows
processes to be overridden at appropriate levels.
Take the following items into consideration when implementing Domain Separation:

Chapter 8.6 Introducing Domain Separation PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapter 8.6 Introducing Domain Separation PDF

Hochgeladen von

Copyright:

Verfügbare Formate

01/03/2017 IntroducingDomainSeparation

Introducing Domain Separation

Process separation: In process separation, conguration such as Business

UI separation: In UI separation, different domains may have different forms

Data separation: In data separation, records such as other users, tasks, or

role, would only see records for their company.

Applying Domain Separation

A domain is typically related to another domain in a parent-child relationship. The domain

The record's domain is used when applying conguration. Any conguration

Global is technically not a domain. Instead, it is the absence of a domain. If a record is

Understanding domain inheritance

Domain being considered Conguration applied Data visibility

None (so global) Global Global, Domains A, B, and C

A Global, Domain A Global, Domains A, B, and C

B Global, Domains A and B Global, Domain B

C Global, Domains A and C Global, Domain C

The rules have the following results:

Global data is always visible, and global conguration is always applied

A record in domain A will only be affected by congurations that are

Turning on Domain Separation

Turning on Domain Separation

If you wish to activate it on a standard ServiceNow instance, log into the Hi

Looking at Domain Separation

3. To see a graphical representation of this, navigate to Domain Admin > Domain

The DomainExtensionsInstaller plugin contains scripts that automatically set the

Exploring domain visibility

Understanding Delegated Administration

Displaying different messages for different domains

Add message: <ticked> (In the Actions tab)

User records in the Initech domain (such as InitechEmployee in the

User records in the ACME domain (such as ACMEEmployee in the following

Creating more domain relationships

Using Domain Separation appropriately

Domain Separation is sometimes seen as a magic x for separation needs. Although it is a

Das könnte Ihnen auch gefallen