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.

[staceybailey]

Darren, to add to what Michelle has already shared,

• There is a table collection attribute called global_visibility that, when set to true, tells the system to essentially ignore domain when determining visibility.   Only contextual security will be applied to limit visibility.   I've only seen a few appropriate use cases for this, but it's good to know.   It opens visibility, but process will still run according to the domain.
  (Bottom line: Can Domain Separation be activated for some applications but not others?   YES)
• As Michelle mentioned, there are some applications, like Service Catalog and now Knowledge (in Fuji), that are intentionally not domain-separated because they rely on other mechanisms like user criteria to determine visibility to items.   Best practice is not to try to domain separate "OOB" applications that are not separated by the plugin.   Development likely has a good reason for not going down that path.   When in doubt, submit a question to support to ask.

[Deepak Ingale1]

Hi Stacey,

Catalogs are not domain separated and can be controlled by using entitlement scripts and fields. I totally agree with this.

Now questions is, I have almost a same flow (+/-   Approval cycle) for all my customers. How do I accommodate all those to single workflow without configuring switches in workflow to determine what domain record is submitted and to achieve that slight variation. We even can not override the global workflow to particular specific domain.

What is the best practice in such scenarios. Configuring another workflow should not be a choice right?

[staceybailey]

Deepak,

The easiest way I have found to deal with such situations is to put the parameters on the company record.   Then, you don't have to figure out what domain the record was submitted in.   Instead, in the workflow, just set the approval group to (the equivalent of) current.company.<approval_group>.   You can achieve the variations by dot-walking through to the company record.    

We had a change approval process that different for clients.   Some had 1 approval tier and others had 2. Some required one approval in the first tier and all members of the 2nd tier to approve, etc.   So, we added a form section on the company record to specify Tier 1 group, Tier 1 approval criteria, Tier 2 group, and Tier 2 approval criteria.   Then, within the workflow for (in this case) the change, we knew the company of the change record and were able to dot-walk to get the groups and criteria.   If there were no values in Tier 2, we skipped that and just went with one set of approvals.   That worked for the majority of our customers.

With Fuji, we can start to get really fancy, though I haven't tried this myself.   With the domain support in workflows now, you can have your general workflow in global and have it call sub-flows with full support for domain overrides.   So, essentially, you can splice in a domain-specific approval sub-flow but have your general workflow control the overall process.  

Configuring separate workflows is always a choice, but you have to consider that you will have to maintain it, regression test it for all major upgrades and releases, etc.   Best to minimize that type of thing and maintain fewer, smarter flows.

[Deepak Ingale1]

Hello Stacey,

Thank you vey much and appreciate your great help on this.

We are even now looking for lookup like you have mentioned with respect to company.

We might create totally different table for this to accomplish this task.

About overrides to workflows in domain separation, that feature is present in Eureka release as well, apparently it gets applied to Changes but however does not get applied to catalog items. Reason may be the 'Workflow' is reference field for catalog item.

This is a great thread going on so far with really good questions and answers.

[MadhuriGudiseva]

Apologize for the delay. We had some technical difficulties at start. The event is live now.