No, alerts only offer the possibility to send out notifications, no scripts or automations. But that’s fortunately not necessary, alerts work a little different. 
Alerts are an entity, and so you can use it to act as a trigger for all kind of different scripts or automations.
This is just a minimal example:
input_boolean:
hallway_frontdoor_open_notify:
name: Frontdoor open!
icon: mdi:alert
template:
- binary_sensor:
- name: hallway_frontdoor_open_alert_active
state: "{{ is_state('hallway_frontdoor_contact_on_off', 'on') and is_state('input_boolean.hallway_frontdoor_open_notify', 'on') }}"
delay_on: '00:00:30'
alert:
hallway_frontdoor_open_critical_alert_active:
name: Frontdoor open
entity_id: binary_sensor.hallway_frontdoor_open_alert_active
state: 'on'
repeat:
- 1
can_acknowledge: false
skip_first: false
title: "Critical warning"
message: "Frontdoor is open!"
done_message: "Frontdoor is now closed!"
notifiers:
- NOTIFY_critical
data:
tag: hallway_frontdoor_open_critical_alert_active
What you’re doing here, you have an input_boolean to disable the alert, but not by turning on or off the alert itself, but rather a template binary_sensor. That comes in handy later for display and setting purposes.
The binary_sensor itself is a nice way, to cover all fancy conditions and sensors in one more or less short way. An alert wouldn’t be able to handle complex criterias.
That brings us to the alert, here you are just reacting on the binary_sensors state. I don’t want to get in to deep here, if you have questions what does what in an alert, please ask.
As you have different possibilities to work here, one could be an automation reacting on the state of the alert. It’s easy, because you have three alert states:
| State |
Description |
idle |
The condition for the alert is false. |
on |
The condition for the alert is true. |
off |
The condition for the alert is true but it was acknowledged. |
Regarding your telegram notification. HA has an integration for that, that works great. This is the part of the notifications in that alert (NOTIFY_critical):
notify:
- name: notification_telegram
platform: telegram
chat_id: !secret telegram_chat_id
- name: NOTIFY_critical
platform: group
services:
- service: mobile_app_1
- service: mobile_app_2
- service: notification_telegram
- service: notification_tv
data:
data:
duration: 10
fontsize: medium
position: center
color: grey
transparency: 0%
I’m using telegram here as another notification channel. One sends via HA companion app a notice, one per telegram and one to the TV.
Depends on what mqttwarn additionally does, but for “simple” notifications I’d use something like the above.
I unfortunately can’t say how groups work in UI, haven’t tested it (yet). In general, groups are just a list of entities, and as the entities are identical in your automation, it just makes sense to use. If you need to change something, you wouldn’t need to change two things in one automation, but just in one place => the group. And it would make it easier to read in the automation.
Yes the device_id was a general advice, it just messes up things (in my opinion). Here you use it:
- alias: When Zigbee2MQTT Bridge gets disconnected
type: not_connected
platform: device
device_id: 42fe7de51c4f0b1c10f721444cf8c34e
entity_id: 945c77990f996fba5ff40da68e80f17f
domain: binary_sensor
id: Zigbee2MQTT Disconnected
for:
hours: 0
minutes: 2
seconds: 0
And for the modification strategy, see above: groups 
Hope this helps a little, as always, if you have questions, ask!