Dynamic CI Groups - default number of CIs

[Anton Perepelit]

Hi all,

I am currently building an ownership model according to this documentation:

https://docs.servicenow.com/en-US/bundle/sandiego-servicenow-platform/page/product/csdm-implementati...

The problem I have is that Dynamic CI Groups are limited to 10.000 CIs on default, so other CIs exceeding the number within that class will not be subject to data inheritance.

I thought of two ways to solve this: 
1. Split a bigger group into two or three, so each would have 10.000 CIs in it. 
2. Adjust the default max default number of CIs and increase it.

If we are talking about the second option:

Does anyone know where and how I can do it on the platform?
Do you know if increasing the number would have a bad performance impact on the platform?
Do you have additional concerns regarding the topic?

Thank you!

[Martin Grosskop · Accepted solution]

Hi Anton,

The property you need to change is sa.qbs.max_num_of_cis.

The property might not exist - so you will probably have to create it. (type = integer)

We are currently running with a value of 40 000 without any noticeable impact.

Regards

Martin

[Anton Perepelit]

Hi Martin,

Thank you. It worked!

[Suhail2297]

sa.qbs.max_num_of_cis.   -  Do i need to add . (dot) at the end?

[Mathew Hillyard]

Hi @Martin Grosskop 

I'd be interested to know how you are using this. ServiceNow put a limit on this for a reason. Let me give you an example:

You want to choose a Service Offering on a Incident and have it filter the Configuration Item field to only those CIs that are linked to the Service Offering via a Dynamic CI Group. Building this query does not permit you to create a dedicated reference qualifier on the Configuration Item field because the CIs linked to a Dynamic CI Group are held in the Service Configuration Item Association table. The only way to filter the CIs is to query this table and return a "Sys ID IN" reference qualifier, which as you may be aware is not very efficient. For a regular App Service this is fine as few App Services have more than a few dozen CIs linked, but Dynamic CI Groups are much larger. At approx 25,000 CIs in a Dynamic CI Group and testing the above use case I found a production instance took about 90 seconds to load the popup window when clicking the magnifying glass icon next to the Configuration Item field. with 40,000 CIs it took 5 minutes to render.

You may not need to do this, but this is very helpful in Incident and Change when picking either a CI and filtering Service Offering or vice versa, and if you find you want to do this in future then you may have to reorganise all your Dynamic CI Groups. RaptorDB may render this issue obsolete but it is unfortunately an issue today.

There's also no real justification to have such a massive group of CIs in one Dynamic CI Group - any Service Offering with that many related CIs is at too high a level and should be broken down using foundational data into smaller components. Companies often don't/can't do this because they haven't fixed their foundational data before embarking on CSDM.

I hope this helps!

Mat