When to use 'ignore cache' on 'sys_properties recordsIssue NOTE: This article is written to explain the behavior of system properties and direct customers when creating new system properties. The 'ignore cache' field of out-of-box properties, on the other hand, should not be changed unless otherwise directed by ServiceNow. If you create a new system property in your ServiceNow instance, should almost always have 'ignore cache' set to "true" on 'sys_properties' records. Let us explain why. One particularly confusing topic regarding Glide System Properties (records in the sys_properties table) is the performance impact incurred when they are changed. When you change a Glide Property it can cause a system-wide cache flush leading to potentially severe performance degradation for anywhere from 5 to 30 minutes. In some very rare cases, the cache flush can even bring nodes down hard enough that the load balancer takes them offline, thus resulting in temporary session imbalance and causing hours of impact. ServiceNow is a clustered platform with multiple "nodes" or JVMs working as what appears to the internet as a single "instance" of ServiceNow (e.g. acme.service-now.com). Properties are cached in node memory, meaning each node in the cluster has its own copy of each property. This is a way of avoiding database calls for commonly accessed property values. When a property is changed on one node, the other nodes dump their property caches and get the new value of all their properties from the database again. This has a completely trivial impact on system performance. This part happens regardless of if the ignore_cache field is set to true or not. However, if ignore_cache is set to false - this was the default value until the Rome release - then we not only flush the specific cache related to properties, but we also flush the whole Glide System cache!! Let me say that again and, please, pay attention to the double negative. If a property is set to not ignore the cache, then we are telling it to flush the whole Glide System cache! This is what triggers the significant performance impact. So why would we do it? The reason that this cache flush is done is so that we make sure to flush any dependencies or stale values in other caches that might be related to the old value of the property that was just changed. For example, imagine that you have a UI cache that stores the rendered HTML of a page on the server-side, on a per session basis. The purpose of a such a cache would be to avoid rendering the same page over and over for the same user. Now suppose further that the way the HTML renders depends on the value of a property that was just changed. If we don't flush this UI cache then the old value of the property will still be getting used in the rendered HTML and any changes you expect to see in the UI based on the change of the related property would not reflect in the UI until the user starts a new session - i.e. until they log out and log back in. In this scenario you would want to make sure that ignore cache is set to false so that we will not ignore the cache flush, thereby ensuring that any dependent cache would also be flushed. So, in summary, unless you have some very good reason that the entire system cache needs to be flushed when a Property is changed, then set ignore_cache = true. That way the system will only flush the property-specific cache when the property is updated and not the whole Glide System cache. Thus, you will avoid the performance impact of a whole system cache flush.