Workspace Task Page Configuration Changes Not Reflecting Due to sn_grc_workspace_wq_cache_data Cache

[NikhilSingh22_]

Hi Community,

I am facing an issue with a ServiceNow Workspace configuration and would appreciate any guidance from those who have encountered something similar.

Scenario: I updated the Task Page Configuration for a workspace, including:

• Modifying tab configurations
• Deactivating certain tabs
• Updating layouts/components

The changes were saved and published successfully. However, the workspace UI does not consistently reflect these updates. In several cases, the previously configured tabs continue to appear even after being deactivated.

After investigation, it appears that the workspace is still utilizing cached data from the sn_grc_workspace_wq_cache_data table, causing the UI configuration to remain out of sync with the latest Task Page Configuration changes.

Questions:

1. What is the recommended approach to force workspace page configurations to refresh and bypass stale cache entries?
2. Is manually clearing records from sn_grc_workspace_wq_cache_data considered a safe/recommended practice?
3. Are there any platform cache flush mechanisms, jobs, or best practices specifically for GRC/IRM Workspaces that should be used instead?
4. Has anyone experienced similar synchronization delays between Task Page Configuration updates and workspace rendering?

Any insights, best practices, or ServiceNow-supported approaches would be greatly appreciated.

Thank you!

[musislam · Accepted solution]

Hi Nikhil,

Thanks for coming back with that. The property test tells us the most: with caching off, your tabs show correctly. So your Task Page Configuration is fine, and the real problem is that the cache isn't being cleared when the config changes.

It also explains why none of the flushes worked. sn_grc_workspace_wq_cache_data is a table, so its data sits in the database. cache.do and gs.cacheFlush() clear in-memory caches and don't delete those rows.

While the case is open:

• Find what writes to it. Search Business Rules and Script Includes for wq_cache_data to see what builds the cache and what's supposed to clear it. If the clear only runs when the main config record changes, editing or turning off a tab would never clear it. That would match what you're seeing.
• Try one toggle. Set the property to false, load the workspace, then set it back to true. If the cache rebuilds with your new tabs, you can use that as a step after each release until support replies.
• Give support the evidence. Send the property name and your on/off test result. Add the stale cache row's sys_updated_on next to the config record's, plus your GRC: Common Workspace Elements version.

It's fine to leave caching off for now. The cache probably exists to speed up the work queue, though, so keep an eye on load times for large queues.

Could you post what support comes back with here, including any KB or PRB number? That way the next person who hits this can find it.

If that helps you get it sorted, mind marking it as the recommended solution? Helps me support these better for the community.

[musislam]

Hi NikhilSingh22_,

Good instinct tracing it to a cache, but I would push back on one assumption before you touch that table.

1. Is manually clearing sn_grc_workspace_wq_cache_data safe or recommended?

Nobody can honestly tell you it is. That table is not documented anywhere - no product doc, no KB, no release note, no community thread. It is an internal implementation table in the GRC Common Workspace elements family, alongside sn_grc_workspace_task_page_config. More broadly, ServiceNow documents no supported technique for fixing anything by deleting rows out of a cache table. The supported surface is the flush mechanisms below, not row-level edits. So deleting from it is an undocumented DB-level workaround, and if it does break something you will be diagnosing that on your own with no reference to work from. I would not do it in an environment you care about.

2. Confirm the cache is actually your problem first.

Before anything else, open the workspace in a fresh incognito window, or as a different user holding the same roles. That bypasses session and browser-level caching completely. If your change renders correctly there, your problem is client or session caching and has nothing to do with that GRC table. Worth knowing that the chrome_main UX page property governs how many canvas instances are cached per session - that is exactly the mechanism that makes one user see the new layout while another still sees the old one.

3. The supported refresh path, in escalating order.

- In UI Builder: hamburger menu > Developer > Clear UI Builder Cache. Start here.

- Clear the browser cache, or retest in a clean incognito session.

- Targeted flush: find the specific cache in cache_inspect.do (filter on Private), then run gs.cacheFlush("<cache name>") from Scripts - Background. Far cheaper than the blunt option.

- cache.do for a full instance flush across cluster nodes. This is the documented escalation but treat it as a last resort - the instance rebuilds its caches afterwards and everyone on the node feels it. Maintenance window, not a routine step.

- If a full cache.do still does not surface the change, that is no longer caching lag, that is a defect - and it is a Now Support case rather than something to work around.

4. One thing specific to Task Page Configuration worth ruling out.

Task Page Configuration [sn_grc_workspace_task_page_config] is a classic configuration record, not a UI Builder macroponent, so the caches in play are the standard form and list caches rather than the UI Builder canvas cache. Two things catch people here:

- The records are scoped per workspace and per table, so it is easy to be editing a configuration that is not the one the workspace in front of you actually reads.

- Administering them needs sn_grc_workspace.task_admin, and configurations carry an Active flag. A tab that "will not deactivate" is very often a second active configuration further down the list rather than a stale cache.

Confirm you are editing the record the workspace actually consumes before concluding it saved and got cached.

5. Has anyone else hit this?

Yes, though it usually gets reported as a UI Builder problem rather than a GRC one - changes persisting in the editor but not rendering until a cache clear is a long-standing complaint across workspaces generally. On the GRC side specifically there was a Tasks page automatic-refresh defect reported after Washington DC where the page hung on load, and a ServiceNow employee pointed at KB1641591 for it. Different symptom from yours, but worth a look if you are on that release family.

Net: rule out 2 and 4 first, then work down the supported list in 3, and leave the cache table alone. If a full flush genuinely does not fix it, raise it with Now Support rather than deleting rows out of an undocumented internal table - that is precisely the situation support exists for.

If this helps you get it sorted, would you mind marking it as the recommended solution? It helps me keep supporting these workspace and platform questions properly, and it makes it much easier for the next person hitting stale workspace configuration to find a resolved answer in the Community.

Macki | Deloitte AU | Engineer Lead

[NikhilSingh22_]

Hi @musislam, So After considering all your points. Here is my analysis.

* Confirm the cache is actually the problem? Definetly it is GRC Cache not browser or Client Cache. * Follow the supported cache refresh path? None of the option worked for flushing the cache.

* Verify the Task Page Configuration itself? So, Yes the Task page configuration is correct if you set the system property to false that enables the system the workspace queue for cache the output comes as expected.

Raised a Now Support case for further investigation. In the meantime, feel free to share any additional insights or experiences that may help identify the root cause.

[musislam · Accepted solution]

Hi Nikhil,

Thanks for coming back with that. The property test tells us the most: with caching off, your tabs show correctly. So your Task Page Configuration is fine, and the real problem is that the cache isn't being cleared when the config changes.

It also explains why none of the flushes worked. sn_grc_workspace_wq_cache_data is a table, so its data sits in the database. cache.do and gs.cacheFlush() clear in-memory caches and don't delete those rows.

While the case is open:

• Find what writes to it. Search Business Rules and Script Includes for wq_cache_data to see what builds the cache and what's supposed to clear it. If the clear only runs when the main config record changes, editing or turning off a tab would never clear it. That would match what you're seeing.
• Try one toggle. Set the property to false, load the workspace, then set it back to true. If the cache rebuilds with your new tabs, you can use that as a step after each release until support replies.
• Give support the evidence. Send the property name and your on/off test result. Add the stale cache row's sys_updated_on next to the config record's, plus your GRC: Common Workspace Elements version.

It's fine to leave caching off for now. The cache probably exists to speed up the work queue, though, so keep an eye on load times for large queues.

Could you post what support comes back with here, including any KB or PRB number? That way the next person who hits this can find it.

If that helps you get it sorted, mind marking it as the recommended solution? Helps me support these better for the community.

[NikhilSingh22_ · Accepted solution]

Hi @musislam,

Regarding the Business Rules and Script Includes approach, it only supports creating records. There is currently no option to update the payload or remove a specific payload entry for a tab configuration that has been set to Display = false. We are awaiting a proper resolution from ServiceNow on this behavior.

The toggle option itself is working as expected. However, when the system property is set to false, the functionality behaves correctly, but enabling it again does not clear the existing data stored in the table. As a result, the previous configuration remains cached and continues to be displayed.

At the moment, the only available workaround is to keep the system property set to false. However, this may impact performance by slowing down the page loading process.

We are currently waiting for further guidance and a recommended solution from ServiceNow.

Thank you for your support.

Nikhil | KPMG | Associate-Consultant