# 4 Update operations
#### Overview
Update operations allow you to be notified when problems are
[updated](/manual/acknowledges#updating_problems) by other users, i.e.:
- commented upon
- acknowledged
- severity changed
- closed (manually)
Update operations are available in actions with the event source as
*Triggers*.
Both messages and remote commands are supported in update operations.
While several operations can be added, escalation is not supported - all
operations are assigned to a single step and therefore will be performed
simultaneously.
#### Configuring an update operation
To configure an update operation:
- Go to the *Update operations* tab in action
[configuration](/manual/config/notifications/action)
- Click on *New* in the Operations block
- Edit the operation details and click on *Add*
Several operations can be added.
Update operation attributes:
|Parameter|<|<|<|<|Description|
|---------|-|-|-|-|-----------|
|*Default subject*|<|<|<|<|Default message subject for update notifications. The subject may contain [macros](/manual/config/notifications/action/operation/macros).|
|*Default message*|<|<|<|<|Default message for update notifications. The message may contain [macros](/manual/config/notifications/action/operation/macros).|
|*Operations*|<|<|<|<|Update operation details are displayed.
To configure a new update operation, click on *New*.
|
|*Operation details*|<|<|<|<|This block is used to configure the details of an update operation.|
|<|*Operation type*|<|<|<|Three operation types are available for update operations:
**Send message** - send update message to specified user when event is updated, for example, acknowledged
**Remote command** - execute a remote command when event is updated, for example, acknowledged
**Notify all involved** - send notification message to all users who received notification about the problem appearing and/or have updated the problem event.
If the same recipient with unchanged default subject/message is defined in several operation types, duplicate notifications are not sent.
The person who updates a problem does not receive notification about their own update.|
|^|<|Operation type: [send message](/manual/config/notifications/action/operation/message)|<|<|<|
|^|^|*Send to user groups*|<|<|Click on *Add* to select user groups to send the update message to.
The user group must have at least "read" [permissions](/manual/config/users_and_usergroups/permissions) to the host in order to be notified.|
|^|^|*Send to users*|<|<|Click on *Add* to select users to send the update message to.
The user must have at least "read" [permissions](/manual/config/users_and_usergroups/permissions) to the host in order to be notified.|
|^|^|*Send only to*|<|<|Send update message to all defined media types or a selected one only.|
|^|^|*Default message*|<|<|If selected, the default message will be used (see above).|
|^|^|*Subject*|<|<|Subject of the custom message. The subject may contain macros.|
|^|^|*Message*|<|<|The custom message. The message may contain macros.|
|^|^|Operation type: [remote command](/manual/config/notifications/action/operation/remote_command)|<|<|<|
|^|^|*Target list*|<|<|Select targets to execute the command on:
**Current host** - command is executed on the host of the trigger that caused the problem event. This option will not work if there are multiple hosts in the trigger.
**Host** - select host(s) to execute the command on.
**Host group** - select host group(s) to execute the command on. Specifying a parent host group implicitly selects all nested host groups. Thus the remote command will also be executed on hosts from nested groups.
A command on a host is executed only once, even if the host matches more than once (e.g. from several host groups; individually and from a host group).
The target list is meaningless if the command is executed on Zabbix server. Selecting more targets in this case only results in the command being executed on the server more times.
Note that for global scripts, the target selection also depends on the *Host group* setting in global script [configuration](/manual/web_interface/frontend_sections/administration/scripts#configuring_a_global_script).|
|^|^|*Type*|<|<|Select the command type:
**IPMI** - execute an [IPMI command](/manual/config/notifications/action/operation/remote_command#ipmi_remote_commands)
**Custom script** - execute a custom set of commands
**SSH** - execute an SSH command
**Telnet** - execute a Telnet command
**Global script** - execute one of the global scripts defined in *Administration→Scripts*.|
|^|^|*Execute on*|<|<|Execute a custom script on:
**Zabbix agent** - the script will be executed by Zabbix agent on the host
**Zabbix server (proxy)** - the script will be executed by Zabbix server or proxy - depending on whether the host is monitored by server or proxy
**Zabbix server** - the script will be executed by Zabbix server only
To execute scripts on the agent, it must be [configured](/manual/appendix/config/zabbix_agentd) to allow remote commands from the server.
This field is available if 'Custom script' is selected as *Type*.|
|^|^|*Commands*|<|<|Enter the command(s).
Supported macros will be resolved based on the trigger expression that caused the event. For example, host macros will resolve to the hosts of the trigger expression (and not of the target list).|
|^|<|Operation type: notify all involved|<|<|<|
|^|^|*Default media type*|<|<|Users who update a problem but have not received notifications about the problem appearing will receive notifications about further updates on the selected default media type - Email or SMS.
This field is available since Zabbix 3.4.2.|
|^|^|*Default message*|<|<|If selected, the default message will be used (see above).|
|^|^|*Subject*|<|<|Subject of the custom message. The subject may contain macros.|
|^|^|*Message*|<|<|The custom message. The message may contain macros.|