Expanded Search Capability

What is a one sentence summary of your feature request?

It will be nice to expand the search capabilities

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

I think a very needed an over due capability is a better search capability. You can only search devices by an individual device or a group of devices. Often times, you have to deal with a set of devices that may or may not be in the same smart group or custom group. For example:

  1. The Windows/Linux team decommed several servers and advised the security team to decom the servers in their specific securit tool (Trend, Qualys, CT), etc. In CT, I can only work with one server at a time. I should be able to copy several servers into the search field, and all are displayed
  2. Upgrading Agents - I should be able to search agents by agent version. This way I can work only with the servers I need to work with and not have to fiddle through servers that are not applicable.

There’s several more reason that I can provide for sound reasons of expanding the search capabilities to search more than one server at a time.

Such feacher will save hours of work when dealing with hundreds of servers.

How do you currently solve the challenges you have by not having this feature?

I can only work the task one by one. Often times I don’t have time to work one server at a time so the task is put to the rear and the client is informed of the issue to set expectation.

1 Like

Hi Andre,

I agree there are limitations to the search capabilities in the UI for these very specific administration tasks. I’ve taken some time before replying on this one because I’ve been thinking about the impact on the UI. I think we could easily overcomplicate the UI as we start to support more and more complex tasks like this.

My thought is that I’d like to keep the UI simple for simple tasks and recommend the upcoming API client library for more complicated tasks like this. I can imagine a short script that gets (or builds) the list of devices, requests their details from the API (via the client library) and then performs actions on each one in a loop. This would have the additional benefit of making it possible to automate these complex tasks.

It’s great that you have already signed up for the API client library beta program. We should have the first early release very soon and we’ll notify everyone who is a part of the program.

Thanks

Hi James,

Thank you for your response.

To clarify, the request to expand the search capabilities does not introduce additional complexity to the user interface. From a product design standpoint, it’s important to differentiate between individual preferences and strategic functionality. With respect, this enhancement isn’t about personal convenience—it’s about delivering a solution that is scalable, efficient, and aligned with the demands of a data-driven enterprise environment.

Netwrix is already collecting a substantial volume of valuable data. However, the ability to extract actionable insights from that data is significantly hindered by the current limitations in search functionality. At present, similar to a website that only support templates, Change Tracker only supports group-level or single-device queries. This constraint becomes particularly problematic when performing operational tasks such as building a whitelist.

For example, once a source is identified for a qualified whitelist, the process of selecting members becomes unnecessarily manual and fragmented. Servers that need to be whitelisted often span multiple groups. This requires users to repeatedly navigate in and out of different groups—selecting one server from Group A, two from Group B, and so on. When managing hundreds of servers, this process becomes inefficient, error-prone, and operationally taxing. This same limitation also affects other core functions.

What’s especially noteworthy is that the platform already supports filtering by attributes such as online/offline status, compliance state, tracker type, change type, and planned/unplanned status. These filters leverage the same underlying logic that could be extended to support multi-server search directly from the search bar. Given that MongoDB Compass already supports this type of query natively, it’s difficult to justify why the Change Tracker UI cannot offer similar functionality.

Furthermore, to the best of my knowledge, Netwrix Change Tracker is the only FIM solution on the market that lacks the ability to search across multiple servers outside of predefined groups or individual selections. This represents a significant gap in usability and undermines operational efficiency at scale.

I appreciate your consideration and look forward to exploring how we can evolve this capability to better support enterprise-scale use cases.

Best regards,
Andre Cole
Security Delivery Associate Manager