Diagnose and resolve slow loading times in Risksheet by identifying the root cause of the bottleneck and applying targeted configuration and infrastructure optimizations.
Before applying fixes, determine which factor is causing the slow load. Risksheet performance is affected by several independent factors, and the resolution differs for each one.
Polarion background operations can block Risksheet access entirely or cause significant delays.
Open the Polarion administration console
Check whether a historical database reindexing operation is running
If reindexing is active, wait for it to complete before investigating further
Polarion historical database reindexing operations can make Risksheet completely inaccessible. The entire application may fail to load or time out during reindexing. Always check for active reindexing operations before investigating Risksheet-specific issues.
Step 2: Check for Unresolvable Work Item References
Broken cross-project links or references to deleted work items cause expensive server-side exceptions that severely degrade load times.
Open the Polarion server logs (check your server administrator for the log file location)
Search for UnresolvableObjectException errors
If these errors appear during Risksheet loading, they indicate linked work items that do not exist or are inaccessible
Unresolvable work item references cause 40+ second delays per GridItems API call. If your server logs show multiple UnresolvableObjectException entries coinciding with Risksheet requests, the broken links are the primary cause of slow loading. Remove or fix the broken links in Polarion to resolve the issue.
To fix broken references:
Identify the specific work item IDs from the exception messages in the logs
Open the risk items that contain the broken links
Remove the invalid link references or restore the missing linked items
The number of item-link and multi-item-link columns has a greater impact on performance than row count alone. A sheet with 250 rows and 17 linked item columns (especially 7 or more multiItemLink columns) will load significantly slower than a sheet with 500 rows and only a few link columns.Split large sheets by FMEA type:Instead of combining multiple analysis types (e.g., usability FMEA and design FMEA) into a single sheet with many columns, create dedicated sheets for each FMEA type. This reduces the column count per sheet and improves load performance.
Approach
Columns
Performance
Single combined sheet (usability + design FMEA)
40+ columns, 17 link columns
Slow (up to 2 minutes for 250 rows)
Separate usability FMEA sheet
~20 columns, ~5 link columns
Fast
Separate design FMEA sheet
~20 columns, ~5 link columns
Fast
Performance degrades primarily from the number of item-link and multi-item-link columns rather than row count. Splitting one large FMEA sheet into dedicated sheets per FMEA type is the most effective optimization strategy.
Add the moduleOnlyPermissions parameter to speed up loading of large sheets. This parameter restricts permission checking to the document level instead of checking per-item permissions, which is significantly faster.
{ "global": { "moduleOnlyPermissions": true }}
The moduleOnlyPermissions parameter was introduced in version 24.8.5. Verify that your Risksheet version supports this property before adding it to your configuration.
By default, Risksheet performs a full data reload after every save operation. For large sheets, this reload adds noticeable delay after each save. Disable it with:
{ "global": { "refreshOnSave": false }}
When refreshOnSave is set to false, the grid keeps its current data in memory after saving instead of fetching everything from the server again. You can manually refresh the page when you need to see changes made by other users.
Disabling refreshOnSave means the grid will not automatically reflect changes made by other concurrent users after your save. Use this setting when performance is more important than real-time multi-user synchronization.
If slow performance occurs specifically during PDF or Excel export rather than during initial page load, the bottleneck is likely cell merging during export rendering.Use Flat Table View for Export:Switch to the Flat table view before exporting. Cell merging is the primary bottleneck for large sheet exports, and using the Flat table view eliminates merging during the export process.
Export Method
Estimated Time (Large Sheet)
Standard view with merged cells
Up to 3 hours
Flat table view (no merging)
3-7 minutes
Steps to export using Flat table view:
Open the Risksheet document
Switch to the Flat table view using the view selector
Start the PDF or Excel export from the Flat view
After export completes, switch back to the hierarchical view if needed
If the server and configuration are not the issue, browser-side factors may be involved.
Clear browser cache — Stale cached resources can cause loading delays
Check concurrent users — Six or more users loading the same Risksheet simultaneously can strain server resources. Coordinate heavy editing sessions during off-peak hours
Verify network connection — High latency between your browser and the Polarion server increases load times for every API call. Each linked item column generates additional server requests during load
Check browser compatibility — Use a supported browser version. See Browser-Specific Issues for details
Long editing sessions may trigger session timeouts that cause apparent “slow loading” when the session expires and forces re-authentication. Risksheet includes a built-in keep-alive mechanism that prevents session timeout during active editing.If you experience periodic slow responses or re-login prompts during long sessions, check that your browser is not blocking background requests to the keep-alive endpoint. See Session Timeout Errors for more information.
