How to limit the number User Preferences?

[Timothy F1]

Issue:

This page on the docs site says "Having more than 10,000 user preferences causes system degradation and UI performance issues." We have quite a few more user preferences than 10k. We've noticed some performance issues. We're not sure if they're related.

What I've done so far:
Reduce the number of preferences by: 

• Deleting system preferences for deactivated users
• Creating defaults for a few of the common user preferences

I'd like to know:

1. Is there a list of user preferences that are no longer needed?
2. How would you tell if it's affecting performance?
3. Are there any preferences that should not be defaulted?
4. What are other ways to stay below 10k?

[Maik Skoddow]

Hi @Timothy F1 

to be honest it's the first time I hear of such a limitation and it makes no sense at all. ServiceNow is storing many

preferences for each user in the background permanently. On a production instance with several hundreds of users you exceed that arbitrary limit pretty fast. OOTB that table already has some indexes so that performance shouldn't be an issue. But to be sure, take a look into the module "Slow Queries" (table sys_query_pattern) and check whether there are any recorded queries regarding the user preferences:

At the moment, I'm more concerned that users are able to create new records in that table by themselves. Some time ago we had a security audit in our PROD instance and the guy who performed that audit had a lot of fun to fill that table with tons of random values.

So at least the new button should be disabled for that table. I wouldn't change the ACLs as I have no idea about the resulting consequences (any broken functionalities, for example).

And if you really think you have performance issues, raise a support ticket with ServiceNow and let them find a solution as we talk about here over base functionalities which should be well-designed and implemented by the vendor.

Maik

[Saurabh Gupta]

Hi,
This 10k is not related to entire platform I believe. Instance with user base suppose 50k must be having user preference record more than 10k. In my current system it is 250k+.

We cannot control the personal user preferences like changing the views etc.

In my system 252k+ user preferences are there still it is working smooth.

[Mark Roethof]

Hi there,

A few years ago I created an Instance Scan check for this, though thinking about it, 10,000 user preferences does not make any sense at all. Unfortunately the docs page does mention this. I think the docs page is simply wrong. Even for my smallest customers they have about 100K, bigger customers 1M+. If the table gets into millions, yes that becomes a performance issue, if a since user has ten thousands of user preferences, yes that becomes a performance issue. Though 10K for the whole system? No way that causes degradation.

Though you do have to spend time on the User Preferences for sure, making it part of daily system administration duties or automatically maintain it.

For example, to cleanup user preferences for users which are inactive for x amount of months, to cleanup user preferences with invalid user reference (might also be a scripted issue behind it you perhaps want to investigate), cleanup user preferences which don't have a user reference and no system set.

Also look into user preferences with system checked, though at the same time users have the same user preference with the same value (= useless!). For example a scripted daily scheduled job (or a scheduled flow?) can clean this up for you.

With simple actions like this, for several customers I've managed to lower their user preferences table with at least 50% (and structurally maintain it using table cleaners and scheduled jobs).

And one final very important detail...
When cleaning such a table up, which can be in several GB of size... you need to have the table rebuild for performance gain on the table itself!