Advanced web form email notifications using tokens

While the default messages that work out of the box are fine in many situations, customizing these emails helps you:

• Acknowledge exactly what the user submitted

• Provide clearer next steps

• Make emails feel personal and intentional rather than generic

The key to doing this safely and confidently is understanding tokens.

What are tokens?

A token is a placeholder in square brackets that is replaced with real data when the email is sent. Think of tokens as fill‑in‑the‑blank labels. You write the email once, and the system swaps in the user’s actual answers when the form is submitted.

For example:

Thank you for your submission, [webform_submission:values:first_name].

When the email is sent, that token might become:

Thank you for your submission, Alex.

You don’t need to write any code to use tokens—just place them correctly in your message.

Why use tokens instead of plain text?

Using tokens lets you:

• Confirm that the form was received

• Reflect the user’s own input back to them

• Reduce follow‑up questions caused by vague confirmations

Compare these two messages:

Without tokens

Thank you for your submission. We will review your information.

With tokens

Thank you for submitting [webform:title].

We’ve received your request for [webform_submission:values:event_title] on [webform_submission:values:event_date].

The second message immediately builds trust because it proves the system understood the submission.

Where tokens can be used

Tokens can be used anywhere plain text is allowed in an email responder, including:

• Subject line

• Email fields (being careful to ensure that “from” is always an “@uwaterloo.ca” email address)

• Message body (after selecting “Custom body…” from the dropdown)

If a field accepts text, it can accept tokens.

Finding available tokens

When editing an email responder, you’ll see a token browser link (labeled “Browse available tokens”) anywhere it’s possible to use tokens.

This tool lets you:

• Explore available tokens by category

• Insert tokens without memorizing syntax

• Avoid typos or broken tokens

Open

You can move and resize the “available tokens” pop-up to see more information without obscuring the handler configuration.

Commonly used webform tokens

Here are some practical tokens you’ll likely use most often:

Submission details

• Submission ID: [webform_submission:id]

• Submission date: [webform_submission:completed]

• Submission URL (useful for admins reviewing entries): [webform_submission:url]

Form field values

Tokens representing user‑entered data usually follow the [webform_submission:values:FIELD_KEY] pattern. For example:

• Name field: [webform_submission:values:name]

• Email field: [webform_submission:values:email]

• Message field: [webform_submission:values:message]

Finding field keys

The FIELD_KEY comes from the form field’s key, not its title.

Open

You can see the field titles and associated keys in the table on the “Build” tab.

The default key is based on the title. It can be helpful to edit this to be something more concise and memorable.

Open

By default, the key is based on the title.

Open

Clicking the “Edit” link lets you set a custom key.

Open

The table on the “Build” tab reflects the custom keys.

Example: a friendly confirmation email

Subject

We received your submission: [webform:title]

Body

Hello [webform_submission:values:name],

Thank you for completing the [webform:title] form.

Here’s a summary of what we received:

• Email: [webform_submission:values:email]

• Topic: [webform_submission:values:topic]

Message:
[webform_submission:values:message]

If you need to make changes, please reply to this email.

Best regards,
The [site:name] Team

This approach reassures users while staying professional and readable.

What happens if a token is empty?

If a user leaves a field blank, the token will usually be replaced with nothing. The email will still send.

To avoid awkward gaps, don’t rely on optional fields for critical messaging. Phrase sentences so they still read well if a value is missing.

✅ Good:

If you included additional comments, we’ve received them.

⚠️ Risky:

Your additional comments were: [webform_submission:values:comments]

What happens if the token is invalid?

If you’ve mistyped a field key, or deleted a field that is still referenced in your email handler, the raw token will appear in the email.

Say you accidentally mistype the “name” field key:

Thank you, [webform_submission:values:nname]. Your submission ID is [webform_submission:id].

The resulting email will look like this:

Thank you, [webform_submission:values:nname]. Your submission ID is 45.

Testing your email responder

Before relying on a customized email responder:

• Submit the form yourself

• Try different combinations

  • All fields filled in

  • Optional fields left blank

• Review

  • Subject line clarity

  • Token replacements

  • Formatting and readability

Testing is the fastest way to build confidence.

Best practices for confidence

• Start small: customize one or two tokens first

• Use the token browser, not memory

• Keep language friendly and forgiving

• Test changes before going live

You won’t break the form by experimenting—email responders are safe to adjust.

When to stick with defaults

Defaults are fine when

• The form is purely internal

• The submission doesn’t need confirmation details

• You don’t want to maintain custom text

Custom responders are most valuable when the email is part of the user experience.