Actions settings

Click on any actions node in the assistant builder to edit it and access its settings.

Node settings

Node name

The name displayed on the node within the assistant builder. It has no effect on the node's operation and will not be shown to the user.

We recommend using a descriptive name of the actions performed by this node, such as "File support ticket" or "Check order status".

Default: "Actions"

User message

A message to be displayed to the user in the assistant while waiting for the node's actions to complete.

This setting is only available if the node includes at least one action that has form data assignments. Because later nodes may rely on that form data, the assistant will not proceed to the next node until the action completes. During that time, the user message will be displayed.

If there are no form data assignments in this node, the assistant will simply proceed to the next node and there is no need to display a message to the user.

Default: "Just a moment..."

Actions

One or more actions that will be executed when this node is reached in a conversation. There are several types of action, each of which has its own settings.

• Create Zendesk Ticket
• Update Zendesk Ticket
• Create Salesforce Case
• Update Salesforce Case
• Send Email
• Call External API

Create Zendesk Ticket

This action requires that you have an active integration with Zendesk.

Create a new ticket in Zendesk with configurable information.

This action type has several settings.

Requester email

The email address to use for the ticket's requester information in Zendesk. There are multiple options described below.

1. Customer email (Default)

If a form with a "Customer email" field has been filled in, use the email address from that field.

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.

3. Email address

A specific email address. If this option is selected, you must also specify the email address 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 using an email address stored in 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 Zendesk ticket will then use the address associated with that key as the requester email.

See Markup expressions and operators for more information on markup syntax.

Requester name (optional)

The name to use for the ticket's requester information in Zendesk. There are multiple options described below.

1. Logged in user's email

If the user has logged in to Mavenoid to access this flow, use the name on their Mavenoid account.

2. Text (Default)

A specific name. If this option is selected, you must also specify the name 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 using a name stored in form data. For example, if the user has provided their name in a form and it is stored with the key "customer-name", you can specify the markup text as "{{customer-name}}". The Zendesk ticket will then use the value associated with that key as the requester name.

See Markup expressions and operators for more information on markup syntax.

Ticket subject

The subject of the Zendesk ticket. 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.

Text contents

The body of the Zendesk ticket. There are multiple options described below.

1. HTML transcript

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 Zendesk ticket and whether it will generate any customer-facing communication (such as from notifications or replies in Zendesk).

2. Text transcript (Default)

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 Zendesk ticket and whether it will generate any customer-facing communication (such as from notifications or replies in Zendesk).

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 ticket contents on form data values. For example, if you want the ticket 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 Zendesk ticket, use HTML tags.

Tags

Any tags to be applied to the Zendesk ticket.

Tags can use markup to reference form data values. For example, to apply a tag based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no tags will be set on the created ticket.

Files

Any files to be attached to the Zendesk ticket.

Files can use markup to reference form data values. For example, to attach the files the user has uploaded in a form associated with the key "screenshots", enter "{{screenshots}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no files will be attached to the created ticket.

Custom Fields

Any custom fields to be set on the Zendesk ticket.

For each custom field, you must specify both a key and a value. The key must be the numeric ID of the custom field in Zendesk. The value can be plain text or can use markup to reference form data values. For example, to set a custom field based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no custom fields will be set on the created ticket.

Initial status

What status the Zendesk ticket will be set to when created.

This will depend on your Zendesk workflow. For example, if you are using this action to file escalated tickets that require further action, you may wish to use "new" or "open". If instead you are using this action to file resolved tickets for your metrics or reference, you may wish to use "solved" or "closed".

Default: Unset.

Brand ID

The numeric ID of a Zendesk brand. The created ticket will be associated with the specified brand.

This is only necessary if you are using Zendesk Multibrand.

Default: None, meaning the created ticket will be associated with your default brand in Zendesk.

Group ID

The numeric ID of a Zendesk group. If set, the created ticket will be automatically assigned to that group.

Default: None, meaning the created ticket will not automatically be assigned to a group by Mavenoid. It may still be automatically assigned by triggers in Zendesk.

Ticket form ID

The numeric ID of a ticket form in Zendesk. If set, the created ticket will use the associated form and display that form's ticket fields.

Default: None, meaning the created ticket will use your default ticket form.

Form data assignments

What form data to set based on Zendesk'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 Zendesk:

• $error: If the Zendesk API returned a failure message, it will be available with this key.
• $ticketId: The numeric ID of the created Zendesk ticket.

Default: None, meaning no form data will be set.

Delay in seconds

How long to wait after reaching this node before creating the Zendesk ticket.

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

Note: If there are form data assignments in place, the delay will be set to "0" automatically as later nodes in the flow may use that form data and therefore rely on the ticket to be created before they can be rendered properly.

Default: "0", meaning the ticket is created immediately when the user reaches this node.

Update Zendesk Ticket

This action requires that you have an active integration with Zendesk.

Update an existing ticket in Zendesk with configurable information.

This action type has several settings.

Ticket ID

The numeric ID of the Zendesk ticket to update.

This field can use markup to reference form data values. For example, if a previous Create Zendesk Ticket action used form data assignments to store the ID of the created ticket with the form data key "ticket-id", you could reference that ticket here by entering "{{ticket-id}}".

See Markup expressions and operators for more information on markup syntax.

Default: None. This field must be set by you.

Ticket subject

For this to be available, you must click "+ Update subject". Otherwise the subject will not be updated.

The new subject for the Zendesk ticket. There are multiple options described below.

1. Problem description

If the conversation has included a search node and the user performed a search, the most recent search performed is used.

2. Free text (Default)

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.

Comment

For this to be available, you must click "+ Add comment". Otherwise no comment will be added.

The body of the comment to add. There are multiple options described below.

1. HTML transcript

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 comment and whether it will generate any customer-facing communication (such as from notifications or replies in Zendesk).

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 comment and whether it will generate any customer-facing communication (such as from notifications or replies in Zendesk).

3. Free text (Default)

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 comment on form data values. For example, if you want the comment 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 Zendesk ticket, use HTML tags.

Tags

Any tags to be applied to the Zendesk ticket.

Tags can use markup to reference form data values. For example, to apply a tag based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no new tags will be set on the ticket.

Custom Fields

Any custom fields to be set on the Zendesk ticket.

For each custom field, you must specify both a key and a value. The key must be the numeric ID of the custom field in Zendesk. The value can be plain text or can use markup to reference form data values. For example, to set a custom field based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no new custom fields will be set on the ticket.

Status

What status the Zendesk ticket will be set to.

This will depend on your Zendesk workflow.

Default: Unset, meaning no change to status will be made.

Form data assignments

What form data to set based on Zendesk'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 Zendesk:

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

Delay in seconds

How long to wait after reaching this node before updating the Zendesk ticket.

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

Default: "0", meaning the ticket is updated immediately when the user reaches this node.

Create Salesforce Case

This action requires that you have an active integration with Salesforce.

Create a new case in Salesforce with configurable information.

This action type has several settings.

Requester email

The email address to use for the case's requester information in Salesforce. There are multiple options described below.

1. Customer email (Default)

If a form with a "Customer email" field has been filled in, use the email address from that field.

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.

3. Email address

A specific email address. If this option is selected, you must also specify the email address 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 using an email address stored in 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 Salesforce case will then use the address associated with that key as the requester email.

See Markup expressions and operators for more information on markup syntax.

Requester name (optional)

The name to use for the case's requester information in Salesforce. There are multiple options described below.

1. Logged in user's email

If the user has logged in to Mavenoid to access this flow, use the name on their Mavenoid account.

2. Text (Default)

A specific name. If this option is selected, you must also specify the name 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 using a name stored in form data. For example, if the user has provided their name in a form and it is stored with the key "customer-name", you can specify the markup text as "{{customer-name}}". The Salesforce case will then use the value associated with that key as the requester name.

See Markup expressions and operators for more information on markup syntax.

Ticket subject

The subject of the Salesforce case. 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.

Text contents

The content of the Salesforce case. There are multiple options described below.

1. HTML transcript

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 Salesforce case and whether it will generate any customer-facing communication (such as from notifications or replies in Salesforce).

2. Text transcript (Default)

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 Salesforce case and whether it will generate any customer-facing communication (such as from notifications or replies in Salesforce).

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 case contents on form data values. For example, if you want the case 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 Salesforce case, use HTML tags.

Custom Fields

Any custom fields to be set on the Salesforce case.

For each custom field, you must specify both a key and a value. The key must be the numeric ID of the custom field in Salesforce. The value can be plain text or can use markup to reference form data values. For example, to set a custom field based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no custom fields will be set on the created case.

Origin

What origin to set on the Salesforce case.

This will depend on your Salesforce workflow.

Default: Unset, meaning no origin will be set.

Status

What status the Salesforce case will be set to.

This will depend on your Salesforce workflow.

Default: Unset, meaning no change to status will be made.

External ID name and External ID value

The name and value of the external ID in the Salesforce API. Both must be set to be used.

Default: Unset, meaning no external ID will be used.

Form data assignments

What form data to set based on Salesforce'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 Salesforce:

• $error: If the Salesforce API returned a failure message, it will be available with this key.
• $objectId: The numeric ID of the created Salesforce case.

Default: None, meaning no form data will be set.

Delay in seconds

How long to wait after reaching this node before creating the Salesforce case.

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

Note: If there are form data assignments in place, the delay will be set to "0" automatically as later nodes in the flow may use that form data and therefore rely on the case to be created before they can be rendered properly.

Default: "0", meaning the case is created immediately when the user reaches this node.

Update Salesforce Case

This action requires that you have an active integration with Salesforce.

Update an existing case in Salesforce with configurable information.

This action type has several settings.

Case ID

The numeric ID of the Salesforce case to update.

This field can use markup to reference form data values. For example, if a previous Create Salesforce Case action used form data assignments to store the ID of the created case with the form data key "case-id", you could reference that case here by entering "{{case-id}}".

See Markup expressions and operators for more information on markup syntax.

Default: None. This field must be set by you.

Subject

For this to be available, you must click "+ Update subject". Otherwise the subject will not be updated.

The new subject for the Salesforce case. There are multiple options described below.

1. Problem description

If the conversation has included a search node and the user performed a search, the most recent search performed is used.

2. Free text (Default)

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.

Comment

For this to be available, you must click "+ Add comment". Otherwise no comment will be added.

The body of the comment to add. There are multiple options described below.

1. HTML transcript

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 comment and whether it will generate any customer-facing communication (such as from notifications or replies in Salesforce).

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 comment and whether it will generate any customer-facing communication (such as from notifications or replies in Salesforce).

3. Free text (Default)

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 comment on form data values. For example, if you want the comment 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 comment, use HTML tags.

Custom Fields

Any custom fields to be set on the Salesforce case.

For each custom field, you must specify both a key and a value. The key must be the numeric ID of the custom field in Salesforce. The value can be plain text or can use markup to reference form data values. For example, to set a custom field based on the value associated with the form data key "request-type", enter "{{request-type}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no new custom fields will be set on the ticket.

Status

What status the Salesforce case will be set to.

This will depend on your Salesforce workflow.

Default: Unset, meaning no change to status will be made.

Files

Any files to be attached to the Salesforce case.

Files can use markup to reference form data values. For example, to attach the files the user has uploaded in a form associated with the key "screenshots", enter "{{screenshots}}" as the value.

See Markup expressions and operators for more information on markup syntax.

Default: None, meaning no files will be attached to the updated case.

Form data assignments

What form data to set based on Salesforce'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 Salesforce:

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

Delay in seconds

How long to wait after reaching this node before updating the Salesforce case.

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

Default: "0", meaning the case is updated immediately when the user reaches this node.

Send Email

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.

Call External API

Make an HTTP request to an external API endpoint. The results of the call can be stored as form data.

This action type has several settings.

Request type

Which method to use for the HTTP request to the external API. Currently, the available options are "GET", "POST", and "PUT".

Default: "GET", meaning that an HTTP GET request will be sent.

URL

The URL of the external API endpoint.

Note: The URL can be dynamically generated from form data. To include the value associated with a given key, use the syntax {{key}}. For example, to access a URL based on an order number stored as form data associated with the key "order-number", you can write a URL like https://api.example.com/order/{{order-number}}.

Default: None. You must specify the URL to use.

Timeout (seconds)

How many seconds to wait for the HTTP request to time out. If no response is received before the specified time elapses, the request will time out and no form data assignments will occur.

This must be set to an integer no less than 1 (one second) and no greater than 120 (two minutes).

Be careful when adjusting this value. Longer timeouts will allow slower operations to complete but can mean that users will be waiting for longer. Operations that take a long time to complete may not be a good fit for API calls made from flows.

Default: "4", meaning that API calls that do not return within four seconds will time out and no form data assignments will occur.

Headers to send

Headers to send as part of the HTTP request. For each header, specify the key and the value.

Note: A value can be dynamically generated from form data. To include the value associated with a given key, use the syntax {{key}}. For example, to send a header with key "x-api-version" and the form data value associated with the key api-version, set the header key to x-api-version and the value to {{api-version}}.

Header values also have access to the reserved form data key $secrets. This is a map of names to values for your organization's secrets. For example, to use an OAuth 2.0 Bearer Token stored as a secret named "bearer", set the header key to Authorization and the value to Bearer {{$secrets["bearer"]}}.

Default: None, meaning no extra headers will be sent.

Payload type

This option only available for request types "POST" and "PUT".

What format the API request payload is in. There are multiple options described below.

1. JSON (Default)

Send the request payload as a JSON object. If this option is selected, the payload must also be specified in the "Data to send" field, which defaults to {} for an empty JSON object.

Note: The payload can be dynamically generated from form data. To include the value associated with a given key, use the syntax {{key}. For example, to create a payload using a product number stored as form data with the key "product-number", you might write a payload like { "product": {{product-number}}, "action": "update" }.

2. URL-Encoded Form

Send the request payload as a URL-encoded form. If this option is selected, the payload must also be specified as a set of key/value pairs in the "Form to send" field, which defaults to an empty pair.

Note: A value can be dynamically generated from form data. To include the value associated with a given key, use the syntax {{key}}. For example, to send a form item with key "product" and the form data value associated with the key product-number, set the key to product and the value to {{product-number}}.

This API call has side-effects

If checked, the product assistant will prevent the user from backing through this node so that it will not be triggered multiple times. We recommend you strongly consider checking this box if the API call you are making is not idempotent.

Default: Unchecked, meaning the user is not prevented from backing through this node and the API request can easily be made multiple times.

Response type

The expected format of the HTTP response body. Currently, the only available options are "JSON" and "String".

If response type is set to "JSON", then Mavenoid will attempt to parse the response body as a JSON string. If the body is invalid JSON, no form data assignments will occur. If instead the response type is set to "String", then Mavenoid will not attempt to parse the HTTP response body.

Default: JSON, meaning that Mavenoid will attempt to parse the response body as a JSON string and invalid JSON will prevent form data assignments from occurring.

Allowed statuses (comma separated)

A set of HTTP status codes to allow. You must specify the first digit of each code as a number but the other digits can be replaced with "x" as a wildcard.

If the API response has an HTTP status code that does not match any of the listed statuses, no form data assignments will occur.

For example, to allow all success statuses and also the status code 418 but reject all other statuses, you could set the values to 2xx and 418.

Default: "2xx", meaning that only success statuses are allowed and other response statuses will prevent form data assignments from occurring.

Form data assignments

What form data to set based on the API 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 API server:

• $status: The numeric HTTP status code of the API's response.
• $headers: A JSON array of the HTTP headers included in the API's response. These can be accessed using JSON array syntax and are case-sensitive. For example, to refer to the value of the "Content-Language" header, you would write $headers["Content-Language"].
• $body: The body of the API's response. The format depends on the response type. If it is "String", the value of $body will be a string containing the entire response body. If the response type is instead "JSON", the value of $body will be a JSON array. You can use JSON array syntax to refer to values within such a body. For example, if the response body is { "order": { "id": "4123724", "status": "processing" } } then the value of $body["order"]["status"] will be processing.

Note that any of the following events will prevent form data assignments from occurring:

1. The HTTP request does not receive a response before the specified timeout duration passes.
2. The HTTP response has a status code that does not match any of the allowed statuses.
3. The response type is set to "JSON" and the HTTP response body is not valid JSON.

The conversation will still proceed along the flow, but this action will make no changes to form data. This means that the easiest way to account for API errors is usually by using the "Fallback" option on later read data nodes.

Default: None, meaning no form data will be set.

Delay in seconds

How long to wait after reaching this node before making the API call.

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

Note: If there are form data assignments in place, the delay will be set to "0" automatically as later nodes in the flow may use that form data and therefore rely on the API call to be made before they can be rendered properly.

Default: "0", meaning the API call is made immediately when the user reaches this node.