Assistants

Edit forms in the dashboard

Build a capture form, write the email and text message it sends, and preview both before anyone receives one.

The REST API is how capture forms are provisioned and automated. The dashboard is the other way in, and for writing an email by hand it is usually the better one.

Overview#

Each assistant has a Capture Forms tab holding the same forms the API manages, and the editor calls the same endpoints. A form built here can be read and changed over the API afterwards, and a form created over the API opens in the editor, so the two are safe to mix on one form. The endpoints themselves are in the Capture Forms API reference.

Prerequisites#

An assistant for the form to belong to. If you do not have one yet, create an assistant first.

If the email is going to carry a logo or any other image, host the image somewhere publicly reachable first and have its URL to hand. There is nothing to upload here, and images must already be hosted explains why.

Find the editor#

Open Assistants in the sidebar, click the assistant, then open its Capture Forms tab, beside SMS Reasons and Transfer Reasons. The tab shows a count once the assistant has forms.

The list gives each form its name and trigger, how many questions it asks, how many email and SMS recipients it has, and which of its three messages are customized. Each row carries a switch, an Edit button and a delete button. Deleting asks you to confirm and cannot be undone.

The switch on a row is live

Flicking a form's switch in the list takes effect at once, with no save step behind it. Switch a form on there and it starts running on the next call.

Build a form#

Add capture form opens a panel with three tabs.

Details#

Name the form, write the trigger that tells the assistant when to run it (The caller asks for a call back from a human.), and write the intro message it says to open the form (Sure, I just need a few details so the team can call you back.). Both are ordinary sentences, read by the assistant rather than matched literally.

The Active switch on this tab is part of the form and applies when you save it, unlike the switch on the list.

Questions#

Add one question per answer you need. Each takes a key, the question the assistant asks out loud, a type of String or Number, and a required switch.

The key is the name your messages refer to, so choose it deliberately. It has to be lowercase snake_case and unique on the form, and it is also what labels the answer in the ready-made answer lists, which are built from the key and never from the question. A contact_email key is what the recipient sees above that answer, so contact_email reads better than q2. Writing your own email body lets you lay the answers out and label them however you like instead.

Reorder questions by dragging a row's grip handle, or with the up and down buttons on the row. Rename a key that one of the messages still refers to and the editor says which messages are affected and offers to update them for you, rather than leaving a placeholder pointing at a name that no longer exists.

Delivery#

Who receives the results, and the three messages OnCore sends them.

Add recipients as email addresses, as phone numbers in +E.164 form (+15550001234, no spaces or dashes), or both. At least one recipient is required and the panel will not save without one.

Write the email and text message#

Below the recipients, Delivery holds the three messages: Email subject, Email body and Text message. Each starts on the platform's standard layout and stays there until you press Customize.

Customize opens an empty editor. It does not copy the standard layout in for you to edit, so you are writing the message from scratch. Reset to default goes back to the standard layout and discards what you wrote.

Subject and text message are plain text. Email body is a plain HTML editor and expects a complete HTML document, exactly as emailBodyTemplate does over the API. Something like this is enough to start from:

html

<!doctype html>
<html>
  <body style="font-family: Arial, sans-serif; color: #111">
    <img src="https://cdn.example.com/logo.png" alt="Example Motors" height="40" />
    <h2>{{form_name}}</h2>
    <p><strong>{{caller_name}}</strong> asked for a call back on {{callback_number}}.</p>
    {{details_block}}
    <p style="font-size: 12px; color: #666">Call reference {{call_id}}</p>
  </body>
</html>

Swap caller_name and callback_number for the keys your own form uses. Style it with inline attributes the way email clients expect, and keep every image as an absolute URL.

The placeholder picker#

A customized slot lists the placeholders it accepts in two groups, the form's own fields and the built-ins, and clicking one inserts it at the cursor.

{{details_block}} and {{details_text}} are the ready-made list of everything the caller answered, formatted for the email and for a text message. They are the shortcut if you do not want to place each answer yourself. {{logo_img_html}} inserts the platform's own logo rather than yours, so for your own branding write an <img> tag instead.

The list differs per slot, because the three messages render differently. Email body offers {{details_block}} and {{logo_img_html}}; text message offers {{details_text}}; the subject line offers neither, because it is plain text and would show the raw markup. Built-in placeholders sets out the rules the picker is applying.

The editor catches a typo as you write#

A placeholder matching neither a field key nor a built-in is flagged under the editor with the nearest name that would have worked, so {{frist_name}} on a form with a first_name field reads Unknown placeholder {{frist_name}}. Did you mean {{first_name}}?. The same check runs on save, and a form with a broken placeholder cannot be saved.

Preview before you save#

The bottom of the Delivery tab renders each customized message with sample answers filled in, the email body in a frame and the other two as text. Only customized messages are previewed. A slot still on the standard layout says so instead, so the standard email and text message cannot be previewed here.

Some answers skipped re-renders everything as it arrives when the caller declines the optional questions. Optional answers vanish and the wording you wrote around them stays, so a sentence built around an optional answer has to still read as a sentence without it. It is worth toggling on every message you write.

What the preview cannot show#

The editor notes both of these on screen.

Images you host do not appear in it. The dashboard page's content security policy restricts where images may load from, and the preview inherits it, so your logo shows as a broken image there. The delivered email loads it normally.

Four built-ins are shown as samples. {{heading}}, {{details_block}}, {{details_text}} and {{logo_img_html}} are assembled by the platform from its own configuration, so the preview stands in a representative version of each: a sample heading, a grey placeholder logo, and answer lists built from the sample answers. The delivered message uses the platform's own. {{form_name}} and {{assistant_name}} show the real form and assistant names. The sample answers themselves are invented, {{call_id}} included, so read the preview for layout and wording rather than for content.

What the editor does not cover#

The per-question action, wait_for_response and prompt settings, and the form's properties, are API-only and do not appear here. They are described in Manage capture forms.

Editing in the dashboard does not drop them. A form provisioned over the API keeps every one of those settings when someone opens it to reword the email.

Next steps#

Manage capture forms: the same form over the API, including the placeholder rules the editor applies for you.
Capture forms: what the feature does and when to reach for it.
Create an assistant: the assistant a form belongs to.

PreviousManage forms NextIntroduction