Setting Up Email Notification for Service Requests

Commander provides two methods for setting up email notification for service requests.

  • The first method, configuring email notification within approval and completion workflows, allows you to create dynamic recipient lists and customize the email body.
  • The second method allows you to configure a global set of service request notification triggers and a global set of email addresses.

In this topic:

Method 1: Customized email notification using workflow steps

You can add a Send Email step to your approval and completion workflows to notify users of events in the service request lifecycle.

Example: Email notification in an approval workflow for new service requests

Send a customized email to the person who submitted the request, letting them know that their request was received and when they can expect to receive their service.

email_notif_approval_wf_new

See Creating Approval and Pre-Provisioning Workflows to learn more.

Example: Email notification in a completion workflow for change requests

Notify the owner of a VM that the VM has been decommissioned and will be deleted.

email_notif_compl_wf_change

See Creating Completion Workflows to learn more.

Formatting the email body

The <a> tag is automatically added to links in emails (only the HTTP protocol is supported). For example, if the value of a custom attribute is a link, the value will be formatted as a link in the email.

If you don't use HTML markup in the email body, the body is assumed to be plain text; <br> and <p> tags are automatically added for new lines.

If you add HTML markup to the email body, however, no additional tags are added.

Method 2: Global email notification

You can configure a global set of per-request notification triggers. For example, an administrator assigned to fulfill a service request can be notified at important milestones during the request lifecycle, and the user who submitted the request can receive status updates. You can also configure a set of email addresses that will receive notifications for all service requests.

Notifying users directly related to a service request

Access through:

Configuration > Self-Service > Notification > For Each Request

Available to:

Commander Role of Superuser and Enterprise Admin

To notify users of events for service requests they're associated with:

  1. Under For Each Request, for each type of user (assigned administrator, request submitter and VM owners), select a notification level as detailed in the following table:

    Notification Level Selected

    Triggers

    All

    Any change to the service request, including all state changes and comments made about the service request.

    Caution: When this option is selected, a large number of emails may be sent.

    Basic

    Any change in the state of the service request, that is, when a service request is submitted, approved, completed or rejected.

    Done

    When a service request is completed or rejected.

    None

    None.

  2. Click Save.

Notifying administrators about events related to any service request

Access through:

Configuration > Self-Service > Notification

Available to:

Commander Role of Superuser and Enterprise Admin

Commander can send notification emails to any email address when any of the following events occur for any request:

  • Request approval
  • Automated deployment issues
  • Automated change request fulfillment issues
  • Scheduled change request fulfillment failures
  • Approval and completion workflow step failures

To notify an individual of important events for all service requests:

  1. Under For All Requests, click Add.
  2. In the Manage Service Request Notifications dialog, enter an email address in the text box.
  3. Click the ellipsis.

    If the email address is associated with a Commander user account, the account details are displayed.

  4. Click OK.

Troubleshooting notification email content

On certain occasions, information in a provisioning email may differ from the actual state of a service request. This can result from actions occurring after the email is sent or before it's received.

  • An acknowledgment email may show a cost of zero even though the cost has been calculated for the service and is displayed on the Service Request landing page. In this case, use the hyperlink in the email to confirm the details.
  • The first email sent about post-deployment may not contain the correct resource information that was part of the request or was modified as part of the deployment. In this case, add a "Wait for Service to Obtain IP Address and DNS name" step in a completion workflow to allow time for the resources to be determined properly. See Workflow Steps Reference.