Feature Requests

Submitted By: Lamont Largie The Challenge The current 2000-character limit on JMESPath queries in the Metric builder is a significant constraint for creating advanced, high-value metrics. As our team and our partners strive to "work smarter, not harder," we are building increasingly sophisticated queries that consolidate multiple data points into a single, actionable insight. A prime example is our comprehensive "Windows 11 Compatibility" metric. This query checks all hardware and software requirements in one go and, more importantly, generates a human-readable list of specific reasons for non-compliance. This allows an MSP to see why a machine is incompatible without running multiple reports, saving significant time. However, due to the number of checks and the logic required to generate detailed error messages, this metric is at the absolute edge of the character limit, forcing us to abbreviate heavily and preventing further enhancements. Proposed Solution We request that the maximum character limit for JMESPath queries be substantially increased, for instance, to 4,000 or 8,000 characters. A higher limit would remove the current ceiling on metric complexity and empower users to build more powerful and efficient reports. Business Value & Justification Increasing this limit directly aligns with Liongard's core value proposition of providing deep data visibility and automation: Drives Efficiency: It allows for the creation of "all-in-one" metrics that reduce the number of individual reports a technician needs to run and correlate. This saves time and reduces the chance of human error. Enhances Actionability: Complex queries can provide more than just raw data; they can deliver contextual, actionable insights. Our Windows 11 metric is a perfect example—it doesn't just say "fail," it says "fail because RAM is too low and Secure Boot is off." This level of detail is what our partners need. Unlocks New Use Cases: Many other complex scenarios (e.g., detailed security posture audits, comprehensive configuration change reports) are currently difficult or impossible to implement because the necessary query logic exceeds the character limit. Reduces "Metric Sprawl": Without the ability to build comprehensive metrics, users are forced to create numerous smaller, single-purpose metrics, which can clutter the system and make it harder to manage. Use Case Example The "Windows 11 Compatibility Metric with Error Details" (the query we've just finalized) is our primary use case. It showcases the desire to perform multiple conditional checks and concatenate custom strings—both of which consume characters rapidly. Allowing this query to be expanded would enable us to add even more value, such as checking for specific CPU models or providing more detailed remediation advice directly within the metric's output. Thank you for your consideration. This enhancement would be a significant quality-of-life improvement and would be greatly appreciated by my team and the partners we support.

Metric to show which mailbox is delegated to whom would be very handy.Send As and Full permission information would be ideal.

Allow us to view the Metric ID without having to go into the metric to grab the ID.This makes PowerBI Reporting easier, when you can have a list of metric IDs in 1 place, rather than loading each metric separately

If you change a lot of metrics or want to see which metrics have been changed recently, it is nice to be able to select a column in the Metric overview where the date/time of the metrics has been changed. So you can also filter on this.

As a user, I'd like to be able to return a calculated metric value to put it on my Environment dashboard.DifferencesSumDimensionsBetween a static number and a metricBetween two or more metricsDays until or since a dateLatest metric value compared to the same metric in a point in timeSince the previous inspectionPrevious dayThe prior weekDay in a weekFirst of the month

Have noticed come metrics that never get turned on for a partner, or that no longer pull back data due to either Liongard inspector updates, or changes to the API pull. Just need an overall cleanup.

A partner would like the ability to filter the SQL databases that are being monitored and alerted on without creating a custom metric to exclude them.

I designed a metric around the Azure Active Directory inspector but this could apply to any. My situation is that a customer would like alerts when the membership of a certain subset of their Microsoft Teams changes (and thus, the membership of the underlying AzureAD groups of type "Office" that underly the Teams system). These are high-value groups where more sensitive organization files are stored so they want us to be alerted when the membership changes, even if an in-house IT staff member adds themselves to the group inappropriately.The query I wrote for this (with a few display tweaks from Brett on your support team!) is:Groups[?contains( ["Human Resources","Finance"] , displayName) && groupTypeStr=='Office'].['Teams Group:', displayName, '| Members:', members[]. userPrincipalName]This is specifically for the "Azure Active Directory" inspector, but the concept I'm proposing would apply to any metric that could return an array where you want to filter the results of what to include, so I'm not tagging this idea as just for Azure Active Directory as the idea is not specific to that.This retrieves a list of groups with the names matching those in the "contains" array, along with a list of all the members of each of the groups, and we have an actionalable alert just for this one client's environment that will alert us of changes to the membership in these groups specifically.However, if we wanted to do the same for other customers, or our own internal environment, we have to clone the metric, rename it, apply it to a different alert template for that one client, all because the list of groups for one customer would likely be different than for another customer. In theory, we could keep a large list and it would only match the groups that exist in any given customer, but then if one customer had one of those groups but did NOT want alerts, we couldn't do that.My suggestion is to have some way to template Metrics in a way that we could have the one query/metric, but be able to customize part of the metric on a per-customer/per-environment basis, so pass in a different array of Teams AzureAD group names for one customer than another, but using the same metric/rule/alert/template.This does seem a bit advanced, but I could see it being used for multiple things where you wanted to alert on changes of only a subset of results (the changes to membership of certain groups and not ALL groups, like this) across different inspectors and environments pretty powerfully, while reducing alerts on things that aren't as high-importance, and in turn reducing alert fatigue and support load for technicians.

Via a Metric, allow the user to set a threshold from the current count, or from a set value. For instance, if X changes away from 5 or if X changes from 10% of 5. This should be correlated with an Actionable Change Alert rule.

For inspectors that are individual system based, SQL, Windows, Cisco IOS, Cisco ASA, HP Procurve, Fortigate etc build a data repository representing aspects of the systems to be used in an environmental metric - first such thought is a count of the number of systems in that environment for that inspector.Consider the possibility of building a metric adding number of systems across inspectors, i.e. number of network devices across Cisco IOS, Cisco ASA, Fortigate etc