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(, 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.