Instance Management - Alerts

^^^ That’s the right answer.

Those workarounds do not excuse the false presentation of instance “groups”, which are in fact instance “tag” (not “tags”, which might actually be somewhat helpful with accompanying tag support).  Since there is no group object associated with an instance tag they of course cannot apply thresholds or anything to new instances -- they are acting as macros at the time you apply changes and that is all. When I run into these sort of poor design decisions, I remember a lot of the core product was written by UCSB students (which is not necessarily bad, but in many cases here it is and it shows).  And folks at LM are clearly not interested in improving the core since they consider it “good enough” and a waste of resources to improve versus adding new features that can be licensed for additional $$. The only option you have as a user is to leverage the API to get stuff like this to work the way you want.

I vehemently disagree with using cloning of datasources for anything other than as a starting point for a new module. I lost the battle long ago to have module cloning leverage inheritance so you could actually derive modules without creating a maintenance nightmare, just as I lost the battle to get “templates” to actually be templates and not strings with unconditional token substitution.

Agreed. There are certain fundamental things that really should get attention beyond the MVP state they are in.

Talk to @Michael Rodrigues about his plans for DS clone parentage. It’s almost exactly what you’re talking about. However, until it’s released, it’s similar to UIv4 and websites moving to the resources tree and services moving to the resources tree.