Send an email with configurable recipient address, subject line, and message body.

This action type has several settings.

Send email to

The recipient of the email message. There are multiple options described below.

1. Customer email
   If a form with a "Customer email" field has been filled in, use the email address from that field.
    
   This can be useful for sending users a copy of any request submitted on their behalf.

2. Logged in user's email
   If the user has logged in to Mavenoid to access this flow, use the email address on their Mavenoid account.
    
   This can be useful for sending users a copy of any request submitted on their behalf, but only if the user is logged in to Mavenoid.

3. Email address (Default)
   A specific email address. If this option is selected, you must also specify the email address to use.
    
   This can be useful for sending notification emails or for sending requests to ticketing systems that do not have a built-in integration.

4. Markup
   Text in which any markup will be evaluated. If this option is selected, you must also specify the markup text to be evaluated.
    
   This can be useful for sending emails to addresses determined by other form data. For example, if you've determined the user's region and have their regional technician's email stored as form data with the key "regional-technician-email", you can specify the markup text as {{regional-technician-email}}. The email message will then be sent to the address associated with that key.
    
   See Markup expressions and operators for more information on markup syntax.

Hide message recipients

If unchecked, the email will be sent with the recipient in the TO line.

If checked, the email will instead be sent BCC so that the recipient addresses are not visible in the message itself.

Default: Unchecked, meaning the email will be sent with the recipient in the TO line.

Email subject

The subject of the email message. There are multiple options described below.

1. Problem description (Default)
   If the conversation has included a search node and the user performed a search, the most recent search performed is used.

2. Free text
   Any specific text. If this option is selected, you must also specify the text to use.

3. Markup
   Text in which any markup will be evaluated. If this option is selected, you must also specify the markup text to be evaluated.
    
   This can be useful for basing the subject on form data values. For example, if you want the subject to be "Request submitted:" followed by the value associated with the form data key "request-type", you can specify the markup test as "Request submitted: {{request-type}}".
    
   This field also has access to the reserved form data key $transcript. You can thus use {{$transcript["subject"]}} for the "problem description" (the last search performed by the user) or {{$transcript["body"]}} for the full text of the transcript of the conversation.
    
   See Markup expressions and operators for more information on markup syntax.

Email body

The body of the email message. There are multiple options described below.

1. HTML transcript (Default)
   The full transcript of the conversation and all form data that is not marked as PII, formatted as HTML.
    
   If this option is selected, you must also specify whether to include live support messages (defaults to yes) and live support agent notes (defaults to no) from any live support chats that occurred as part of this conversation. When making this decision, consider who will receive the email and whether it will generate any customer-facing communication (such as by filing a ticket in a help desk system).

2. Text transcript
   The full transcript of the conversation and all form data that is not marked as PII, formatted as plain text.
    
   If this option is selected, you must also specify whether to include live support messages (defaults to yes) and live support agent notes (defaults to no) from any live support chats that occurred as part of this conversation. When making this decision, consider who will receive the email and whether it will generate any customer-facing communication (such as by filing a ticket in a help desk system).

3. Free text
   Any specific text. If this option is selected, you must also specify the text to use.

4. Markup
   Text in which any markup will be evaluated. If this option is selected, you must also specify the markup text to be evaluated.
    
   This can be useful for basing the message body on form data values. For example, if you want the body to read "User <CUSTOMER_EMAIL> has filed a <REQUEST_TYPE> request" with the placeholders replaced by the values associated with the form data keys "email" and "request-type", you can specify the markup text as "User {{email}} has filed a {{request-type}} request".
    
   This field also has access to the reserved form data key $transcript. You can thus use {{$transcript["subject"]}} for the "problem description" (the last search performed by the user) or {{$transcript["body"]}} for the full text of the transcript of the conversation.
    
   See Markup expressions and operators for more information on markup syntax.

Note: Unlike many other fields, markdown in this field will not be parsed. If you need to format the contents of your email body, use HTML tags.

Form data assignments

What form data to set based on the mail server's response. This data can be used by other nodes later in the flow, will be included in the conversation transcript, and is viewable on the agent dashboard if the conversation includes a live chat.

Like a write data node, you can add any number of form data assignments for this action to perform. For each one, you must specify the key to update and the value to set it to. Note that all values are treated as already being in double-curly-braces, meaning that to reference the key name you would enter "name" instead of {{name}}.

All normal form data keys and all global reserved form data keys are available. Additionally, the following limited reserved form data keys are available, allowing you to set values dynamically based on the response from the mail server:

• $error: If the mail server returned a failure message, it will be available with this key.

Delay in seconds

How long to wait before sending the email.

This provides a grace period during which the user can go back to an earlier point in the flow, such as because they have changed their mind or they have realized that they provided incorrect information and want to update it. If the user backs through the node before the delay has elapsed, the email will not be sent, preventing superfluous or unintended emails.

Default: "0", meaning the email is sent immediately when the user reaches the node.