ServiceNow caches configuration such as dictionary entries, business rules, ACLs and UI policies to keep the platform fast. Because of that, a change you make may not take effect immediately, and in a multi-node instance the caches must be synchronized.
Before you start
You should be comfortable with the platform’s configuration objects. This article covers caching behavior and invalidation.
Step-by-step walkthrough
Step 1: Know what is cached
Metadata that is read on nearly every request — dictionary, rules, ACLs — is cached in memory. A change to a cached object is picked up when the cache refreshes, which is usually quick but not instantaneous, so a just-made change can appear not to work.
Step 2: Flush deliberately
The platform offers a cache flush for specific caches or all of them, which is useful when a change does not propagate as expected. Flushing is a diagnostic and a fix, but overusing it masks a deeper issue and briefly costs performance while caches refill.
Step 3: Account for multiple nodes
An instance may run several application nodes, each with its own cache, so invalidation must reach all of them. The platform propagates changes, but during the brief window different requests may hit nodes with different cache states, which can make behavior look inconsistent.
Worked scenario
The flush is targeted at the affected cache.
Cache flush: System Diagnostics > Cache > Flush
- flush the specific cache (e.g. dictionary) first
- flush all only if the target is unclearWalk through the example
Flushing the affected cache forces it to reload on each node, so the change takes effect. A targeted flush is preferred because it avoids the performance dip of refilling every cache. Escalating to a full flush identifies that the change was in a different cache than assumed.
Common mistake
Assuming a configuration change is live the instant it is saved, then chasing a bug that is only cache delay. Another is flushing all caches routinely, which hides the real cause and costs performance.
Verify the behavior
Make a configuration change and observe whether it takes effect immediately or after a refresh. Flush the relevant cache and confirm the change appears. On a multi-node instance, confirm the behavior is consistent across nodes after propagation.
Interview exercise
Why might the same request behave differently on two nodes?
Answer and reasoning
Because each application node caches configuration independently, and a recent change may have propagated to one node’s cache but not another’s yet. During that window, requests routed to different nodes can see different configuration. The behavior converges once caches synchronize, and a targeted flush speeds that up.
Continue learning
Compare execution timing in Business rule timing and script APIs in Script includes. Read the ServiceNow caching and cache flush documentation and try the ServiceNow interview questions.