Preconfigured emails are sent in the following scenarios:

• Deployment start – When a deployment starts, an email is sent to the release manager and, if you are using branches, to the operator who started a deployment.
• Deployment step failure – If any step in the deployment process is unsuccessful, the deployment pauses. An email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Deployment step completion – When a step in a deployment process is completed, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Deployment completion – When a deployment is successfully completed, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Stage completion – When a stage in a deployment process is completed, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Stage failure – If a stage fails to be completed, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Manual tasks requiring approval – When a manual task requires email approval from a user, an email is sent to the user, who can approve or reject the task from the email.
• Stopped deployment – When a deployment is stopped, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Pega unit testing failure – If a Pega unit test cannot successfully run on a step in the deployment, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Pega unit testing success – If a Pega unit test is successfully run on a step in the deployment, an email is sent to the release manager and, if you are using branches, to the operator who started the branch merge.
• Schema changes required – If you do not have the required schema privileges to deploy the changes on application packages that require those changes, an email is sent to the operator who started the deployment.
• Guardrail compliance score failure – If you are using the Check guardrail compliance task, and the compliance score is less than the score that is specified in the task, an email with the score is sent to the release manager.
• Guardrail compliance score success – If you are using the Check guardrail compliance task, and the task is successful, an email with the score is sent to the release manager.
• Approve for production – If you are using the Approve for production task, which requires approval from a user before application changes are deployed to production, an email is sent to the user. The user can reject or approve the changes.
• Verify security checklist failure – If you are using the Verify security checklist task, which requires that all tasks be completed in the Application Security Checklist to ensure that the pipeline complies with security best practices, the release manager receives an email.
• Verify security checklist success – If you are using the Verify security checklist task, which requires that all tasks be completed in the Application Security Checklist to ensure that the pipeline complies with security best practices, the release manager receives an email.