Application layering and composition in ServiceNow

[Stefan Clemens]

Dear all,

I have several questions regarding the overall architectural (best practice) setup, capabilities and restrictions of ServiceNow.

Let me try to explain my current situation first - This might help you to understand where I am coming from and why I have such a big headache in because of all mentioned questions 😉 I am familiarizing myself with ServiceNow for some months. I am an experienced Senior Architect for (another) BPM tool, and I am still trying to apply lots of concepts / experiences to the ServiceNow cosmos. Unfortunately, I am really struggling in doing so and I am meanwhile wondering where to find the appropriate information and whether these concepts are applicable to ServiceNow

My questions refer to some basic (but pretty much important) concepts regarding the architectural application setup and application layering.

What I understood so far is that ServiceNow (or the "ServiceNow Platform") comes with a global scope. This scope contains “older” applications such as ITSM. Application scoping was introduced meanwhile for several reasons such as data segregation, development and deployment purposes. New modules, such as HRSD and CSM base on the ServiceNow platform:

 

Let me now try to introduce you to a simple and exemplary setup that I want to use to address my questions:
The international Company “ABC” has decided to use ServiceNow and the HRSD module. There is no other use case than HRSD so far and only subsidiary “Sub1” will use the tool for now. Nevertheless, it might very well be that further subsidiaries will also stick to ServiceNow HRSD in future. An important note is that the particular module (in this case HRSD) takes precedence above the subsidiary.

Following this simple setup, I would want to create an HRSD application just for Sub1. Other tools allow to introduce multiple "application layers" which can base on (one or many) other application (layers). The idea of this approach is to facilitate encapsulation of customizations and it also strengthens reusability. It leads to the following requirements (at maximum extension):

• Customization and grouping of common Platform assets (applicable for the entire ABC corp.) should be possible (lower red rectangle in the below illustration).
• Customization and grouping of common Platform assets (applicable only for Sub1) should be possible (lower blue rectangle in the below illustration).
• ServiceNow HRSD layer extends (enhanced) Platform assets (upper green rectangle)
• Customization and grouping of HRSD assets (applicable for the entire ABC corp.) should be possible (upper red rectangle in the below illustration).
• Customization and grouping of HRSD assets (applicable for Sub1) should be possible (upper blue rectangle in the below illustration).

The grey rectangles indicate what might happen in case a second subsidiary would be enabled to use the tool at a later state. Their customizations were separated from all Sub1 specific assets which might be a pro regarding potential risks and divergent release cycles.

Please find below - after this huge introduction - finally my questions:

• Is any such design pattern applicable for ServiceNow (please keep in mind that it is not only about data separation but that it should also separate specific customizations)?
• Is there a maximum of application layers in ServiceNow?
• Where and how to customize existing modules (such as HRSD) in case you cannot add an additional layer on top of it? (Coming back to the illustration...) Does that mean that all HRSD specific adaptions should be done in HRSD application and scope directly or should I (and if so how... ) create a new scoped application on top of it? If so, how to reuse the entire HRSD logic?
• Where can I get additional resources and examples addressing such kind of issues?

Thank you so much for all your support!

Cheers,
Stefan

[Stefan Clemens]

Dear all,

thank you so much for taking the time and providing so much information on my concern!!!

I think that the most promising approaches are Domain Separation as well as the Scoped App approach. I will delve into both topics during the next days and then get back to you guys - Please be patient with me 😉

Cheers,

Stefan

[Shiva Thomas]

Hi Stefan,

Great question, masterfully explained. ^_^

I successfuly used the same layer approach in my last GRC implementation. Out of the Box GRC is made of 4-5 distinct scopes. I added a new Scoped app to contains all the customization made for one department, who was the only one using GRC.

If that department was to stop using GRC, the customization would be very easy to un-install. If another department was to start using GRC, they may get their own scoped app if their start diverging from OotB.

I had to modify a few elements in the OotB GRC solution, but kept that as something to be avoided as much as possible. In that case, I worked using update set in the OotB GRC or global scopes.

Why did I not go for the Domain Separation approach?

1. Because the customer have a very large existing instance, with many processes in places. Adding Domain Separation would have caused significant impact to the existing processes in place. 
2. The maintenance cost of having Domain Separation enabled can increase quickly if developers don't expertly manage the overhead required by Domain Separation.
3. The layered approach is great when Domain Separation is not available or needed, as it allow a much easier rollback from customization.

To answer your questions:

• I did not found any specific design pattern, but this idea was presented to me as a best practice during a ServiceNow event a 2-3 years ago.
• There is no maximum level of layer, but you should check your licencing aggrement to find if there are possible hidden impacts.
• I did not had any problem in adding an scoped app on top of an OotB scoped app.

∴
Best regards from Switzerland
Shiva :¬,

If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.

[Stefan Clemens]

Dear all,

I want to thank all of you once again for all your replies! (As stated earlier) I am new to ServiceNow and it's a real pleasure to discover that so many experienced people are willing to share their knowledge!

Please allow me to drive the discussion to the next step. I have tried to apply your answers to my current situation (I will come to that in more detail and give also a specific example later). The following table (which is for sure not 100% selective) reveals how I rate the potential approaches regarding relevant aspects:

This would mean that I should push the scoped app approach if the table was right.

My next step was to lay down my major requirements:

• Requirement 1: A new HRSD application (1 instance) should host 2 subsidiaries and guarantee data security
• Requirement 2: The overall implementation approach should be ready to scale
• Requirement 3*: Use the ootb ServiceNow standard (processes) whenever possible and customize fragments only if necessary
• Requirement 4*: It should be possible implement customizations at the most appropriate level (please find the enhanced layer illustration below)
• • Requirement 4a*: A generic building block should be used when there is no specific one (following the principle of oop; classes and inheritance)
  • Requirement 4b*: A specific building block should be used when it "overrides" a generic one (following the principle of oop; classes and inheritance)

 * Not sure whether this is possible in ServiceNow

I have tried to identify appropriate examples for these requirements so that they become a bit more obvious:

From a layering perspective, I would want to position the required artefacts as follows:

My questions now are...

• Do my considerations even make sense in the ServiceNow cosmos or am I totally wrong?
• Do you have any further recommendation or documentation for me?
• How to build such a scoped app approach (how to really implement it?)? How can I create one scope on top of another one so that I can create a structure out of n layers? Is there any kind of documentation targeting that topic?
• As you might have seen, I was not able to properly position the managers in the above layer illustration... How to assure proper data security in this scenario?

Thank you very much for sharing your thoughts on this one once again!

Cheers,

Stefan

[Tom Sienkiewicz]

Hi Stefan,

I worked on a 3-year project for a HR MSP company using Domain Separation and helped a few other clients clean up their messed DS implementation. Let me address your points based on my experience. I will not say DS is the perfect solution in your case, not trying to sell it but hopefully you can get some insight.

- Complexity - DS is only really as complex as you make it. I have used it to separate both data and process between companies but always insisted that we stick to simplicity (clear and basic domain structure, allowing us to separate the data and process on the highest level required). You just need to get a good hang of it and then it actually saves you hours of otherwise tedious customization to get the same sort of distinction.

- Cost - no comment here, what is expensive for one company will be nothing for another.

- Scalability - THIS is one of the greatest advantages of DS - having all your core data and main processes run in the core domain and overriding bits and pieces of the process/configuration the way you need it using child domains is a great way to both keep your core processes intact and same for everyone but add that local flavour wherever possible.

- Maintenance - you need to make sure that your custom tables handle domain logic properly. For OOB tables, this will mostly happen automatically but you still need to verify how that happens. DS does not really make writing scripts much more difficult, the most important thing is to understand the effect your structure will have on the access to data  or execution of configuration 

- Separation of processes - not sure why you put "impossible" for DS here (unless I misunderstood your question) but it is definitely possible and one of the greatest advantages of DS. Let's say you have your global version of Finance Workflow running in the global domain. You can easily create other workflows for sub-domains and override the behaviour of the parent one. Much easier using DS than through customization. Same goes for Business Rules logic, Notifications etc. Not all config can be domain separated, there are some exceptions but most of the time they are logical. I remember only one area in SN where I had to look for a workaround and this was due to some very uncommon requirements of my client (e.g. having users with the same email address in multiple domains - normally you should only have 1 user with  specific email).

- Data separation - this goes without saying. Of course you can "disable" DS in your particular queries if needed, although you probably will not to use this too often.

- Branding - yes you can change branding/logo based on user's domain.

- Portal - yes you can still have one portal for all (but there would be no problem modifying some redirect scripts that would check the user's domain and direct them to their specific portals as well). My client even set up a reverse proxy server for each of their tenants so that we could offer custom urls to all of them. For new instances, there is a great feature OOB - Custom URL support where you no longer need the proxies.

- User access - normally users have access to data from their domain as well as all children. Sometimes you create "technical domains" to store users like managers who should report on data from multiple sibling domains as well. All comes down to clear vision of the company/data structure.

----------

Now in your specific case (HRSD) I am not that familiar with a native HR mechanism for restricting access. I know that in CSM there are Accounts for example - not sure about how you can restrict Cases in HR other than by DS or custom ACLs. It appears the support for DS in HR is still somewhat limited - take a look here:

https://docs.servicenow.com/bundle/orlando-hr-service-delivery/page/product/human-resources/concept/...

But this does not mean you cannot separate the processes as I mentioned - it just means you will need to figure out your own logic for handling the domains as this is not given on a silver plate.

You mention only 2 "tenants" which is a very small number, normally DS environments handle tens if not hundreds of domains. So yes in that case the overhead might be there but if you expect this number to grow, perhaps it is worth investing from the get-go. 

The best time to implement DS is with a fresh instance. Otherwise you would have to figure out where to put all your existing data (by default, everything would end up in global domain).

----

A few more words on the scoped approach. This will not handle your requirement of specific people seeing all data and then some others only part of it. You will still need to create your custom access control logic. Scoped applications are mainly used to ensure your customization does not break or otherwise affect other areas of the system. I would think twice about creating a new scoped application for every tenant - it is possible but a potential nightmare when it starts appearing that 80% of those "separate" requirements could in fact be handled by a common process. Of course you can rebuild apps and grant cross-app privileges etc. but in the end you would be making a bigger mess than by lumping everything in the global scope. Then again I have not tried such a scenario so these are only my gut feelings. I would love to hear how it went after a couple months of usage.

As for docs on scoped apps, there is the whole developer scoped API which you can use. 

https://developer.servicenow.com/app.do#!/api_doc?v=orlando&id=no-namespace

Be aware that there are limitations like e.g. you cannot add your own fields to OOB tables in scope. 

If I were you I would probably consider the scoped application approach for any custom processes I might be building (then again if you aim to use HRSD you will want to use as much OOB as possible) and then custom security configuration or DS to handle data access / process variations.

I would also recommend that you activate DS in your personal developer instance (it's free) and play around with it before jumping to implementation.

Feel free to contact me if you have any specific questions or would like to discuss DS some more!

/rant 😉

[briandunbar]

Heres a table I put together to provide guidance similar to what you have 

For the most part you can do the "layering" (multi-app) you are talking about but there will be times where you run into features in the core products that don't work and behave right with a layered/extended table model since some features are not "platform features" meaning they work anywhere any table for the most part.  For example CAB workbench in ITSM doesn't really act well to "layered" change mgmt apps it's built to use the out of box change table and that is it.  As illustrated on the table going this layered route is considered custom app development and should be treated as such and since the app development is based off out of box product upgrades will become much more complex.  So this comes down to trade offs does the complexity debt = the value derived from the approach.