Problem:
Alerting rules and many other things can be based on custom properties, but not on groups.
The advantage of groups is that they allow you to collect things dynamically. Once the logic is set up, any new nodes or interfaces that meet the criteria will be added to the group.
In our environment we have groups for each machine type, for each "role" of node or interface, etc. For example, we have a group for WAN interfaces, and a group for WAN routers.
Because alerts, etc. cannot reference group membership, a custom property seems like the next best thing to reference. However, there is no built-in way to set a custom property based on group membership. This means that when new nodes and interfaces are added, they will not have the custom properties that the alerts, etc. are looking for.
It seems like there are two solutions today:
1) Use a scheduled task to set the Custom Property in SQL. Run this task regularly. The SQL query that sets the Custom Property is essentially a duplicate of the Dynamic Query that defines the group membership.
2) Use Alerts whose action is to set a Custom Property. The alert trigger is again basically a duplicate of the group's dynamic query.
Potential Solution:
Allow Custom Properties (and any other properties that make sense, such as "Managed State") to be set based on group membership.
Alternatively, allow alerting rules to trigger based on group membership.