Views and View Rules

[vodnalar26]

Hi everyone,

I have configured a scenario where I created 5 custom tables, and for each table, I designed 3 different views (not including a default view).

To control visibility, I also created View Rules based on specific roles assigned to users.

What I Observed:

• When I impersonate users with the respective roles, the View Rules work perfectly — the correct views are displayed as expected.
• However, after I end impersonation and access the same tables using my own account, the system does not show the default view.
• Instead, it continues to display one of the custom views that were configured, even though no View Rule should apply to my user.

[Naveen20]

This is a well-known ServiceNow behavior, and it's not actually a bug with your View Rules — they're working correctly. The issue is related to how ServiceNow persists the last viewed list view in user preferences.

Here's what's happening: when you impersonate a user and navigate to one of your custom tables, ServiceNow renders the view dictated by the View Rule for that role. At that point, the platform stores that view as the last used view for that table in your session or user preference record. When you end impersonation and go back to the same table as yourself, ServiceNow checks for an applicable View Rule, finds none for your account (which is correct), and then falls back to the last remembered view from your preference — which is still set to the custom view from the impersonation session.

ServiceNow's view resolution order is roughly: View Rule match → user's last-used preference for that table → default view. Since your preference got "polluted" during impersonation, it lands on step two instead of falling through to the default.

To confirm and fix this, you have a few options.

Immediate fix: Manually append &sysparm_view= (empty or default) to the list URL for each of those tables. This resets your stored preference back to the default view. You can also clear the relevant rows in sys_user_preference where the name follows the pattern like table_name.list.view for your user.

Clearing preferences directly: Go to sys_user_preference.do and filter where the user is you and the name contains the table name along with "view." Delete those records. Once cleared, navigating to the table again with no matching View Rule will correctly land you on the default view.

Preventing this going forward: This is inherent to how impersonation works — it runs within your browser session. There's no OOTB toggle to prevent view preferences from being written during impersonation. If this is a recurring testing concern, consider using a separate browser or incognito window for impersonation testing so your primary session preferences stay clean.

The key takeaway is that your View Rules are functioning exactly as designed. The "stickiness" you're seeing is the user preference mechanism, not the View Rules misfiring.

[Tanushree Maiti]

Hi @vodnalar26 

Refer this KB :KB0523467 Identifying the view used on a list or form