While there are several existing, in test, and proposed features that nibble at the related topics, there does not seem to be a complete and consistent "look and feel" solution that addresses each of the needs.

The goal is to have feature-complete hysteresis, "change event" and automatic flap detection/mitigation all pulled together, thus removing one of the common complaints voiced about Zabbix.

The UI change will consist of a radio selection, a checkbox ("smart" flap handling", and two optional fields: one for a trigger (recovery expression), and one for a constant, as follows:

Radio selection box for the user to select one of the following:

1. Standard recovery (default): when the trigger condition is no longer met, then recover.
2. No recovery: if the trigger denotes simply a change in state (like a new version of a package or a change in file hash, or host reboot notification) and no recovery notification would be desired/expected, as described in ZBXNEXT-1895 . (Under the hood, a new trigger type would be nice, but at least the zabbix server could automatically and silently return the trigger to "recovered" immediately after actions are processed on it.
3. Advanced recovery condition: selecting this button causes display of a "recovery condition", as described in ZBXNEXT-2118 . This can be used for manual hysteresis or such.

Check box for "smart flap detection" (global option to configure to default "on" or "off")

• perhaps this uses a simple geometric back-off factor for each associated notification and perhaps based on trigger state-change frequency alone (and not an item value)
• back-off factor (or sensitivity) should be controlled by a global "flap sensitivity" value, perhaps an easy-to-use value where, e.g. ".1" means very noisy, "1" means sensible, and "10" means very subdued / suppressive of trigger change notifications; or perhaps it would be time-based, such as "I don't want to be notified of state changes more often that every X minutes; just send a flapping notification."
• Field: If "smart flap detection" is selected, then provide an optional field for a local override.

Manual Hysteresis makes trigger and/or recovery definitions twice as long and tedious. In an environment where hundreds or thousands of triggers are defined, an (optional) automatic hysteresis would add a lot of value. Making the UI for this and for other types of triggers/recoveries consistent and cohesive will also be a big win.

Naturally, standard template rules/inheritance should apply.