Welcome to the BrightGauge Enhancement Forums

It would be really great if either BrightGauge or the built-in reporting engine could pull from Custom Fields as a data source. At the moment, if you want to see a summary of data in any Custom Field, you have to drill into each and every endpoint/site/company and grab the info one datum at a time, which is quite time consuming.

A way to add in Brightguage datasets a "Is_Active" for device availability dataset , OR, a way to exclude machines that have been marked as suspended alerts in RMM.

Either way, it removes machines I no longer desire to see in my server down report, but still maintains my ability to connect to the machines should anything weird ever go down with those servers. (hey, it happens).

The new "Custom Fields" datasets have been introduced as EA/beta.

I have two custom fields that I want to track and report on: APC UPS model name and serial number
I want to have a table of Company, Site, Endpoint, Model name, and Serial number (sorted by the first 4 fields).
None of the offered designs in BG seem to be able to accommodate that construct.

The "list" gauge only has one sort field, so I can get the list sorted by Company, but not the rest.  As a result the data view is extremely skewed with information appearing out of order.

Please provide multiple levels of sort!

CW RMM does not currently return any details around machine drives outside of utilization numbers. Would be looking for inventory details on the RMM Physical Drive data.

Can we have a Scalepad to Brightgauge integration?  Or the ability to have the Scalepad data syncing into CW RMM be accessible via BrightGauge?

I’d love to see the BrightGauge development team move from positional indexing to Unique ID referencing for multi-layer gauges.

Currently, when we build sophisticated gauges with multiple layers and calculated metrics, the formulas appear to be tied to the layer's order (1, 2, 3). If we need to remove an intermediate layer or reorder them for better visual clarity, the "link" to the data often breaks. This requires us to manually re-map the calculation pills to the new layer positions.

I believe moving toward persistent ID-based references would benefit the entire community by:

• Improving Reliability: Reducing the risk of "broken" dashboards after minor maintenance.
• Encouraging Innovation: Allowing us to experiment with more complex, multi-layered data sets without fear of "breaking the logic."
• Saving Time: Freeing up MSP admins to focus on data insights rather than gauge troubleshooting.

Does anyone else run into this when refining their reporting? I’m curious if others have found creative ways to manage layer dependencies, or if this change would help your workflow as much as it would mine.

Hello. There is no patching classification data in the Device Patching dataset for the N-Central Datasource.  Can this be added?  Or be able to see on a machine the status of patches that should be applied per active policy vs all the possible patches that COULD be installed on a machine (drivers, 3rd party, etc)?