Hello @, I believe that this is the way the functionality works at the moment. I would suggest that you submit a feature request here so that our product team can review your request. Thanks!

---

Will do, thanks for confirming!

---

@  Everyone's been begging for this since at least 2013 - I counted about 8 feature requests here.  The current behavior is intended: no one knows why. 

 

The only thing I can advise is get familiar with the API and write your own tools or interface to perform routine management tasks.  We've had to do a ton of custom scripting to manage Webroot since we moved to it a year ago.

 

 

---

@  My best guess is that was originally meant to moderate the load on their internal databases. They may have figured that using Groups would help hide that restriction.

 

But yeah... definitely makes performing maintance on your endpoint population, and such, all the more painful. Especially if/when the GSM/Site UI "loses its place" within that segmented list of endpoints.

 

I would be perfectly fine with being able to submit a job request for a list of endpoints sorted and/or filtered a certain way, and then the web page notifying you when it's ready to provide you with the list to work with.

---

@Bet you're right about the database load.  They're shooting themselves in the foot with some of the interface stuff though.  Because when the interface and reporting features don't give me what I need, I have to write a script to pull the info with the API, which has got to be less efficient than doing it from their side.

---

@  True. Though it could be situation where they're consciously willing to accept those inefficiencies as opposed to dealing with the problems (potential and/or known) they see with the other approach.

 

As I've mentioned elsewhere, I'm not opposed to the general idea of formally queuing up a request. I would just like to be informed upfront about what sort of wait I'd be looking at.

---