Notifications can be sent when a deployment finishes or an approval is required, for example. Notification recipients are defined with the security system roles. See Managing security.
When you set up notifications, you select both the triggering events and the role, which is inherited from the security system, to determine which users receive notification. For example, it is common for an administrator or environment owner to be notified when a work item (as part of the approval process) is generated.
A default notification scheme is available. It does not send any notifications by default. The default notification scheme can be customized but it cannot be deleted.
Notifications are tied to a team, a role, an element (such as an application or an environment), and an event (such as a failed process). When the event happens, the server sends a notification message to each user that has the specified role on the teams that are associated with the element. For more information, see Managing security.
To set up your own notifications, display the Notifications pane: click .
Configure the new scheme. Here, you are setting up the who and when for notifications. Later, you can come back to add more entries to the scheme or edit an existing one.
To add a notification for the notification scheme, click Add Notification Entry, and specify information about the notification, as shown in the following figure:
- Role
- The role corresponds to the roles in the security system. The notification message goes to any user who has the specified role on a team that is associated with the target element. For example, a deployment engineer would be interested in being notified about a failed deployment.
- Type
- This field lists the types of event that can trigger the notification. For example, you can trigger notifications when processes start, complete successfully, or fail.
- Target
- The target is the type of element that triggers the notification, including applications,
environments, and resources.
The Target and Type fields depend on each other. For example, if the Target field is set to Application, notifications are sent only when the Type field corresponds to an application process type. For example, the Process Success event, when paired with the "Application" Target triggers a notification when a process (an application deployment) succeeds. Similarly, the same event type, when used with the environment target triggers a notification when a successful deployment runs in an environment (such as SIT or PROD).
When the Target field is set to Resource, notifications happen only for generic processes, not for application processes.
- Type
- Specify a type of object to limit notifications to.
- Template Name
- The available templates are provided by default and suffice for
most or all needs; they format the email that is sent. Which template
you use is based on why you want to set up a notification and the
recipients of the notification. However, if the default templates
do not suit your needs, you can create your own; see Creating notification templates.
- Application deployment failure/success
- Sends notifications about a specific application to the specified users, which are based on the role setting.
- Generic process request started/Process request started/Generic process success/Generic process failure
- Sends notifications about a process.
- Task created
- This template is used to report on the state of manual tasks.
- Deployment readied
- A specialized email template for notifying people that a deployment is ready.
- Approval created/failed
- These templates are used to notify the status of an approval.
To assign a notification scheme to an application, click the application, go to the Configuration tab, and in the Notification Scheme list, select the notification scheme.
To create notification templates, see Creating notification templates.