What is a one sentence summary of your feature request?
Clicking “View Report” on a State-in-Time report should open an interactive filter panel first, rather than immediately dispatching a full report generation query, so users can define their desired scope before any server-side processing begins.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
Currently, clicking “View Report” on a State-in-Time report — and by extension, Risk Assessment reports built on SIT data — immediately triggers report generation against the full available dataset. Filter options are only accessible after the report has already attempted to load.
This is a usability gap regardless of environment size. Users should be able to define what they are looking for before the product begins processing — not after. Generating a report only to adjust filters and regenerate it is an unintuitive flow that creates unnecessary work and wastes time for every user.
In large environments, this behavior goes beyond a usability concern and becomes a functional blocker. The moment “View Report” is clicked, a query is dispatched against a potentially very large dataset. The user has no opportunity to limit the scope beforehand. They must wait for the full timeout window to expire — which can take 30–40 minutes — before they are even able to interact with filter options. By that point, the report has already failed.
This means that in large environments, every single attempt to find the right filter configuration costs a full timeout window. There is no low-cost way to explore the report iteratively. The first click is always resource-intensive, regardless of what the user actually intended to query.
Proposed improvement:
When a user clicks “View Report” on a SIT-based report, the product should present filter and scope options first — such as monitoring plan, path, or date range — and only dispatch the report generation query once the user explicitly confirms their selections. The current behavior of immediately starting generation on click should be reserved for users who choose to proceed without filters, with an appropriate expectation set around dataset size and potential performance impact.
How do you currently solve the challenges you have by not having this feature?
A partial workaround exists, but it is cumbersome and requires steps outside of Netwrix Auditor entirely:
- In Netwrix Auditor, open the desired report and click “View Report”.
- Wait for the report’s UI elements to appear in the SSRS report viewer, then click the Cancel button.
- Open SSMS, connect to the Reporting Services instance, expand “Jobs” in the left pane, right-click the jobs started by the report generation, and cancel them.
- Return to Netwrix Auditor, apply the desired scope filters, and re-run the report.
This procedure must be repeated every time the user wants to adjust the report scope, and requires administrator access to Reporting Services SQL Instance and familiarity with SSMS — neither of which should be prerequisites for running a report in Netwrix Auditor.