Ask the Expert: Live Chat | Domain Separation

[ServiceNow]

ORIGINAL AIR DATE: Thursday, June 18, 2015 | 10:00 AM (PDT) | 1:00PM (EDT)

Join John Chapin on Thursday, June 18, 2015 as he discusses Domain Separation in this session to examine the basics that include:

• Global Scope
• The Top domain
• Process Domains
• Data Accessibility
• Process Inheritance

John Chapin has been in IT for over 20 years.   Prior to joining ServiceNow he migrated from Remedy to ServiceNow while working for a financial firm in New York city.

Over 4 years ago he came to ServiceNow as an Engagement Manager in Professional Services.   John is currently a Senior Solution Consultant at ServiceNow, working with our MSP partners.

[IamGroot]

Hi,

We have this request to add a new domain in our already existing Domain separated instance. The idea is to migrate data of a different ServiceNow instance into that new domain (a POC). Has anyone done this before and what are the aspects and configuration that gets affected as soon as a new domain is added?

Thanks

Rajiv

[staceybailey]

Rajiv,

This is a very good question and I can appreciate the forethought you're putting into it.   This is actually a very common process for customer on-boarding.   It just happens that your "customer's" legacy system happens to be ServiceNow.   If you already have a customer on-boarding process, it should closely align with your efforts here.

When you get into the actual configuration steps, keep in mind the following:

1 - Create the domain

• You should always create your new domains in the same instance and copy the record via xml to the other instances in your stack.   This is very important!   Domain sys_ids must match.  
• When you create a new domain, be sure to identify the parent domain.
• When you create a new domain, the domain path will calculate.   This field value will look something like !!!/!!(/!!$/.     I assume your new domain will not initially have any children, so this new calculation should be fairly quick.

2 - Import the company

• Use XML to preserve the sys_id of the company, if you can, and copy the company record to other instances in your stack as well
• Associate the company to your domain

3 - Import data

• When importing core data (users, groups, group membership, locations, departments, etc.), be sure to set the company field and domain on imported records
• When importing reference fields, select a 'choice action' of REJECT.   This is important!   You should not be creating incomplete records in related tables upon import.   Such records may not land in your intended domain and may be globally visible or be placed in your Default domain.   It's much better to reject the import row, address the data issue, and re-do.

This is not an exhaustive list, but hopefully it helps you to avoid some heart-ache.  

Best of luck,

Stacey

[IamGroot]

Thanks a lot Stacey for your suggestion and sharing your insight about importing data which we haven't yet taken into consideration to begin with.

Initially we would like to have the new domain in place and ensure all existing mechanisms Business rules, client scripts, UI policy, CDMB fields and drop down values are not affected with the inclusion of new domain, to ascertain that our existing set up runs fine.

Post that we would like to bring in import /develop configuration of the other instance and set it up in our new domain.   Lets see how it goes.

Kindly share if someone has done this already with Do's and Dont's   🙂 and difficulty faced.

Best regards

Rajiv

[Deepak Ingale1]

Hi Stacey,

How do we manage CMDB, Assets, Models and Model Categories in Domain Separated environment.

I can see cmdb_ci as well as alm_assets both tables are domain separated. But this is not the case with Models and Model Categories.

It does make sense at first look seeing that Models are global because if first customer uses the model of Dell Series, the same model could be used by other customers in domain separation.

I am sensing the problem if lets say Microsoft Access 2010 is the model in global table. Now when I see the cost associated with it, it is 139.99$.

This might not be the case for all customers right?

Also, If this model status has to be changed from "In Production" to "Retired" for customer 1, but no change is required for customer 2, then that would become difficult to manage.

Could you suggest some remedy on this kind of situations?

Michael.Fry , david.legrand your comments are also welcome.

Any suggestion from others who have faced this kind of problem and how they have overcome it is also appreciated.

[Michael Fry1]

If it can be domain separated, we separate it. Otherwise we try to get them vanilla with limited customization's. Last thing we want to do is create multiple entries MS Access $139.99, MS Access $110.99, etc.